Title
Definition problems with constexpr functions
Status
drafting
Section
7.7 [expr.const]
Submitter
Nikolay Ivchenkov

Created on 2011-03-08.00:00:00 last changed 10 months ago

Messages

Date: 2023-06-15.19:36:24

CWG 2023-06-15

Definitions of member functions need an "as-needed" treatment. See issues 1890 and 2335.

Date: 2013-10-15.00:00:00

Additional note (October, 2013):

This question also affects function return type deduction (the auto specifier) in member functions. For example, the following should presumably be prohibited, but the current wording is not clear:

  struct S {
    static auto f() {
      return 42;
    }
    auto g() -> decltype(f()) {
      return f();
    }
  };
Date: 2012-02-27.00:00:00

The current wording of the Standard is not sufficiently clear regarding the interaction of class scope (which treats the bodies of member functions as effectively appearing after the class definition is complete) and the use of constexpr member functions within the class definition in contexts requiring constant expressions. For example, an array bound cannot use a constexpr member function that relies on the completeness of the class or on members that have not yet been declared, but the current wording does not appear to state that.

History
Date User Action Args
2023-06-15 19:36:24adminsetmessages: + msg7322
2023-06-15 19:36:24adminsetstatus: open -> drafting
2022-02-18 07:47:23adminsetstatus: drafting -> open
2013-10-14 00:00:00adminsetmessages: + msg4624
2011-03-08 00:00:00admincreate