All good :)

On Tue, 5 Oct 2021 at 10:14, Patrice Roy <patricer@gmail.com> wrote:
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@gmail.com> 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.