Yeah but in my opinion is a lot of duplicated work - instead of just
mandating that each and every C++ feature can be constexpr and only keeping
up to date the minimum required set.

Which means - introducing `constexpr goto` from the beginning and now
instead of guessing what an implementation may be required to do to allow
it - just looking at existing implementations that have allowed it.

Same for the standard library - having each and every method by default a
constexpr duplicate - only mandating a minimum required methods to be
available. And then slowly extending this.

In other words adding new features to the standard should require to add a
thought for the same feature as a constexpr - and then you could talk all
you want what the minimum set should be - but for the next iteration you
will have actual data of implementations.

On Thu, May 25, 2023 at 2:35 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, May 24, 2023 at 12:00 PM sasho648 via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Weird how that should even be concern of the committee. Just give the
> syntax and allow implementations to decide what can they implement as
> `constexpr` or not.
> >
> > Maybe only impose "minimal requirements" for what needs to be able to be
> evaluated at compile time.
>
> ... what exactly would be the point of this? I mean, right now,
> compilers can evaluate *anything* they want at compile-time. Nothing
> is stopping them.
>
> `constexpr` is not for "maybe my compiler can do something with this".
> It's for "when I call this in a place that *requires* a constant
> expression, evaluate it at compile-time". It's not a statement of a
> preference; it's a *requirement*, one that places burdens on the
> compiler.
>
> If you cannot rely on `constexpr` actually being a constant expression
> when you need it to be, then what is the point of the feature?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>