Search code examples
c++c++11generic-programmingnoreturn

Is noreturn part of the signature of a function?

[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";}
Solution

  • "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.