[RFC] P1331: Permitting trivial default initialization in constexpr contexts

[CJ Johnson]

Hi everyone! I'd really appreciate feedback on this EWG/CWG feature/bug fix paper. You can view the Markdown file via Github Gist here: https://gist.github.com/CJ-Johnson/cc5cf8ce5b6eba0114e23182daa8e6de

Any comments, concerns, edits or whatever else would be very much appreciated. I'm a library developer and new to ISO Cpp standards work so I'm learning as I go.

Thanks :D

- CJ

[CJ Johnson]

I neglected to include `r0` in the file name, initially.

Here is the updated link: https://gist.github.com/CJ-Johnson/ad7662d7ad3521866c2048bcfff155f3

[CJ Johnson]

I mistakenly distributed this as P1331R0 before it was ready for the P designation. It was/is still in draft state and so I've changed it to D1331. Here's the new link: https://gist.github.com/CJ-Johnson/18485d3c5d60bdd0d2d5cae4fba7a045

On Sunday, November 11, 2018 at 10:51:59 AM UTC-5, CJ Johnson wrote:

[Matt Calabrese]

I am fond of this paper, however there is an interesting note at the end:

Note: Reading uninitialized instances of unsigned char is not undefined. That being the case, if adopted, this proposal would continue to consider it a special case and would thus permit unsigned char a; auto b = a; in constexpr. 

Doesn't this imply that multiple calls to a constexpr function at compile-time with the same exact arguments, can lead to different results? I believe this is novel for constexpr functions (other supposed tricks that do so do not actually have this property). Would we disallow this from actually forming a core constant expression, or perhaps make it so that it produces consistent results if being constant evaluated?

[Matt Calabrese]

On Wed, Nov 28, 2018 at 12:06 PM Matt Calabrese <cala...@google.com> wrote:

Doesn't this imply that multiple calls to a constexpr function at compile-time with the same exact arguments, can lead to different results? I believe this is novel for constexpr functions (other supposed tricks that do so do not actually have this property). Would we disallow this from actually forming a core constant expression, or perhaps make it so that it produces consistent results if being constant evaluated?

Thinking about it further, I suspect that we might actually have the property of multiple calls potentially producing different results due to constexpr std::bit_cast. 

[CJ Johnson]

You raised some good points! I wasn't sure what the behavior should be. I've changed it now to be an open question under a new section. I also added a question about bit_cast. Hopefully those in EWG will be able to make that determination.

[Richard Smith]

On Wed, 28 Nov 2018 at 09:06, 'Matt Calabrese' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:

On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard - Future Proposals <std-pr...@isocpp.org> wrote:

I mistakenly distributed this as P1331R0 before it was ready for the P designation. It was/is still in draft state and so I've changed it to D1331. Here's the new link: https://gist.github.com/CJ-Johnson/18485d3c5d60bdd0d2d5cae4fba7a045

On Sunday, November 11, 2018 at 10:51:59 AM UTC-5, CJ Johnson wrote:

Hi everyone! I'd really appreciate feedback on this EWG/CWG feature/bug fix paper. You can view the Markdown file via Github Gist here: https://gist.github.com/CJ-Johnson/cc5cf8ce5b6eba0114e23182daa8e6de

Any comments, concerns, edits or whatever else would be very much appreciated. I'm a library developer and new to ISO Cpp standards work so I'm learning as I go.

I am fond of this paper, however there is an interesting note at the end:

Note: Reading uninitialized instances of unsigned char is not undefined. That being the case, if adopted, this proposal would continue to consider it a special case and would thus permit unsigned char a; auto b = a; in constexpr. 

Doesn't this imply that multiple calls to a constexpr function at compile-time with the same exact arguments, can lead to different results?

Not exactly. The value of both a and b in the above is (formally) a special "indeterminate value"; any attempt by the program to observe an indeterminate value results in undefined behavior (but we carve out a special rule to allow indeterminate values to be copied around if you don't look at them). So you don't get two different results, but you might get undefined behavior, which might happen to *look like* two different results.

 

I believe this is novel for constexpr functions (other supposed tricks that do so do not actually have this property). Would we disallow this from actually forming a core constant expression, or perhaps make it so that it produces consistent results if being constant evaluated?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmy9uUrNp4yAX7f%3DOc4p%3DqVqeS0fN11bFVBwtaZ%3Dbu%3DdQ%40mail.gmail.com.

[CJ Johnson]

Right now this is left as an open question. Should I add a potential answer? What do you think the semantics should be?

[Richard Smith]

We permit copying of uninitialized unsigned char objects to allow implementing things like memcpy in plain C++. For constant evaluation, that won't work for other reasons (you can't do byte-by-byte copying of symbolic values), so I think the most reasonable thing would be to say that (in the short term at least), reading the value of an uninitialized object is non-constant regardless of its type. We can revisit that decision if we find a use case, but going in the other direction would be more problematic due to being a potentially breaking change.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/790ba68a-bdbd-48bc-8f84-d71a44ba5c77%40isocpp.org.

[CJ Johnson]

Sounds good to me! Added to the draft :)