I'm vaguely remembered Jens saying during the meeting that it will be ok to just put it to std::exception, that's what I did. 

I think the http://eel.is/c++draft/exception#2  "The what() member function of each such T satisfies the constraints specified for exception​::​what() (see below)." 

and having the added text to https://eel.is/c++draft/exception#5 "Returns: An implementation-defined ntbs, which during constant evaluation shall be encoded with the ordinary literal encoding ([lex.ccon])."

Is enough, as all inherited type from std::exception must satisfy constraints of std::exception::what() which is what I specified.

Hana


On 14. 8. 2024, at 0:05, Tom Honermann <tom@honermann.net> wrote:

I don't think this wording works particularly well. The proposed change is only applicable to the implementation of std::exception::what(); it doesn't impose requirements on the implementations in derived classes. Consider the following example:

#include <exception>
#include <iostream>
constexpr int f() {
  try {
    throw std::bad_alloc();
  } catch (std::exception &e) {
    std::cout << e.what() << "\n";
  }
  return 0;
}
int main() {
  constexpr int i = f();
}

The implementation of std::exception::what() isn't invoked in this case. The applicable wording is therefore [bad.alloc]p2.

const char* what() const noexcept override;

Returns: An implementation-defined NTBS.

I think the new requirement for behavior during constant evaluation needs to be applied individually to each of the what() specifications for exception, bad_exception, bad_alloc, bad_array_new_length, bad_cast, and bad_typeid.

Alternatively, since it has not previously been possible to define a constexpr type derived from std::exception, we could consider adding some blanket wording that does impose requirements on derived classes. There is precedent in [exception]p2 (emphasis mine):

Except where explicitly specified otherwise, each standard library class T that derives from class exception has the following publicly accessible member functions, each of them having a non-throwing exception specification ([except.spec]):

- default constructor (unless the class synopsis shows other constructors)
- copy constructor
- copy assignment operator

The copy constructor and the copy assignment operator meet the following postcondition: If two objects lhs and rhs both have dynamic type T and lhs is a copy of rhs, then strcmp(lhs.what(), rhs.what()) is equal to 0. The what() member function of each such T satisfies the constraints specified for exception​::​what() (see below).

I think it would be reasonable to amend this paragraph to impose the encoding requirement on standard library classes that are usable during constant evaluation.

Tom.

On 7/31/24 5:21 PM, Hana Dusíková via SG16 wrote:
I'm sending an attachment with first draft for R4 containing change discussed today in SG16. I would like all the feedback and help you can give. 

Thanks!
Hana

PS: If you don't care about persistence the change is also here: https://isocpp.org/files/papers/D3068R4.html#literal-encoding (link leading directly to the change)