All good :)

On Tue, 5 Oct 2021 at 10:14, Patrice Roy <patricer_at_[hidden]> 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_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.
>>
>