9

[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";}
jww
  • 97,681
  • 90
  • 411
  • 885
alfC
  • 14,261
  • 4
  • 67
  • 118

2 Answers2

8

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

T.C.
  • 133,968
  • 17
  • 288
  • 421
  • "It's unclear what use such a tag would have.". It is about generic code, I want to construct a variant from a set of function return and leave some of them unimplemented (throw at runtime), whatever these functions return I don't want to add the case to the variant. In some sense I have to distinguish a true executed function returning `void` and a formal `void` return that will never be a returning function anyway. See the technique here, https://arne-mertz.de/2018/06/functions-of-variants-are-covariant/, read towards the end. – alfC Jul 11 '18 at 10:29
5

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.

Petr Skocik
  • 58,047
  • 6
  • 95
  • 142
  • 1
    Well, noexcept is part of the type of the function, so could be noreturn. Even if it is not part of the type, it could be in principle detected at compile time. https://en.cppreference.com/w/cpp/language/noexcept_spec – alfC Jul 10 '18 at 15:41
  • @alfC `int f(void) noexcept; int (*fp)(void) = f;` does *not* compile with my `g++`. – Petr Skocik Jul 10 '18 at 15:45
  • 1
    Either your compiler or your test is broken, then. – T.C. Jul 10 '18 at 17:49
  • Assuming noreturn is part of the type, that assignment could pass type checks. Try it the other way. – Joshua Jul 11 '18 at 00:49
  • In the compiler I have `gcc 8`, both `int (*fp)(void) noexcept; fp = f;` and `int (*fp)(void); fp = f;` compile. This is a good example that `noexcept` can be detected but it is not part of the type of the function. So could be `noreturn` in principle. – alfC Jul 11 '18 at 11:09