I will but did not since. I have collected a lot of information (valuable
information, at that) through many of you and some of the initial
contributors, I just did not find the time to put it together yet. Will do
ASAP.

Le lun. 4 oct. 2021 à 04:05, Matt Bentley <mattreecebentley_at_[hidden]> a
écrit :

> On 11/09/2021 4:19 am, Patrice Roy wrote:
> > Noted; I'll find a way to put in in the document, v2 that I hope to send
> > next week, so please verify that I communicated your thoughts properly
> > when you get it. Thanks Matt!
>
> Just to follow up, did you get anywhere with this Patrice?
>
>
>
>
>
> On 12/09/2021 12:34 am, Patrice Roy wrote:
> > Small personal note : I don't think a switch to turn constexpr off alone
> > can work, as constexpr kicks in with constexpr contexts :
> >
> > unsigned long long factorial(int n) {
> > return n == 0? 1ULL : n * factorial(n-1);
> > }
> > int main() {
> > float arr[factorial(5)]{}; // array of 120 float all initialized
> to 0.0f
> > return factorial(5); // runtime function call
> > }
> >
> > We can debug with the runtime call, but if we turned constexpr off the
> > whole program would stop compiling due to arr.
> >
> > If you think we need a mechanism to selectively disable constexpr, I can
> > add it to the document but we'd need to define the intent more clearly.
>
>
> I think just something which ignores the constexpr on functions and
> always runs them at runtime, is all that's likely to be needed, if I'm
> right about it becoming a performance problem (and I could be wrong if
> the compilers get smart about when they're resolving at compile time vs
> runtime).
> But obviously stuff like "constexpr if" cannot be switched off as the
> non-called branch may create invalid code depending on the arguments of
> the if statement.
>