Is noreturn part of the signature of a function?

Question

[dcl.attr.noreturn] can be used to mark that a function doesn't return.

[[ noreturn ]] void f() {
    throw "error";
}

Is [[noreturn]] part to the identity/signature of a function? can one detect that a function is noreturn at the time of compilation?

For example,

static_assert(is_noreturn(f));

In case it is not, should I adopt a convention an define a tag struct?

struct noreturn_{noreturn_()=delete;};
...
[[noreturn]] noreturn_ f(){throw "error";}

Answer 1

"signature" has a very precise definition. Well, several, depending on the kind of thing you are talking about:

• ⟨function⟩ name, parameter type list ([dcl.fct]), enclosing namespace (if any), and trailing requires-clause ([dcl.decl]) (if any)
• ⟨function template⟩ name, parameter type list ([dcl.fct]), enclosing namespace (if any), return type, template-head, and trailing requires-clause ([dcl.decl]) (if any)
• ⟨function template specialization⟩ signature of the template of which it is a specialization and its template arguments (whether explicitly specified or deduced)
• ⟨class member function⟩ name, parameter type list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), and trailing requires-clause ([dcl.decl]) (if any)
• ⟨class member function template⟩ name, parameter type list ([dcl.fct]), class of which the function is a member, cv-qualifiers (if any), ref-qualifier (if any), return type (if any), template-head, and trailing requires-clause ([dcl.decl]) (if any)
• ⟨class member function template specialization⟩ signature of the member function template of which it is a specialization and its template arguments (whether explicitly specified or deduced)

Attributes are not in any of them.

[[noreturn]] is also not part of the type. It appertains to the function, not its type.

---

can one detect that a function is noreturn at the time of compilation?

No. The rule the committee established for attributes is that "compiling a valid program with all instances of a particular attribute ignored must result in a correct interpretation of the original program". That rule would not hold if you can programmatically detect an attribute's presence.

---

In case it is not, should I adopt a convention an[d] define a tag struct?

It's unclear what use such a tag would have.

Answer 2

If it were part of the type, a properly type checking compiler would not accept e.g., something like:

[[noreturn]] int f(void);
int (*fp)(void) = f;

The above compiles without error. [[noreturn]] is not part of the type. (Incidentally, neither is _Noreturn in C11, where it is placed syntactically into the same category as inline).

As for detecting it, I didn't find any mechanism for it in the C++11 standard draft. A convention such as the one you proposed could allow you to detect it, but you'd be limited to functions that follow such a convention.