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

Discussion:

'CJ Johnson' via ISO C++ Standard - Future Proposals

2018-11-11 15:51:59 UTC

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

--
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-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb4e8d6e-1558-456b-ae85-0aa6069c0992%40isocpp.org.

'CJ Johnson' via ISO C++ Standard - Future Proposals

2018-11-13 18:22:10 UTC

Permalink

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

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

Post by 'CJ Johnson' via ISO C++ Standard - Future Proposals
Hi everyone! I'd really appreciate feedback on this EWG/CWG feature/bug
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' via ISO C++ Standard - Future Proposals

2018-11-28 16:56:49 UTC

Permalink

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

'Matt Calabrese' via ISO C++ Standard - Future Proposals

2018-11-28 17:06:45 UTC

Permalink

On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard - Future

Post by 'CJ Johnson' via ISO C++ Standard - Future Proposals
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
https://gist.github.com/CJ-Johnson/18485d3c5d60bdd0d2d5cae4fba7a045

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' via ISO C++ Standard - Future Proposals

2018-11-28 17:47:24 UTC

Permalink

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
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' via ISO C++ Standard - Future Proposals

2018-11-28 19:03:13 UTC

Permalink

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.

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard -

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?

Richard Smith

2018-11-28 23:21:00 UTC

Permalink

On Wed, 28 Nov 2018 at 09:06, 'Matt Calabrese' via ISO C++ Standard -

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard -

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.

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmy9uUrNp4yAX7f%3DOc4p%3DqVqeS0fN11bFVBwtaZ%3Dbu%3DdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

'CJ Johnson' via ISO C++ Standard - Future Proposals

2018-11-29 00:46:31 UTC

Permalink

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

Post by Richard Smith
On Wed, 28 Nov 2018 at 09:06, 'Matt Calabrese' via ISO C++ Standard -

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard -

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.

Richard Smith

2018-11-29 02:02:35 UTC

Permalink

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.

On Wed, 28 Nov 2018 at 16:46, 'CJ Johnson' via ISO C++ Standard - Future

Post by 'CJ Johnson' via ISO C++ Standard - Future Proposals
Right now this is left as an open question. Should I add a potential
answer? What do you think the semantics should be?

Post by Richard Smith
On Wed, 28 Nov 2018 at 09:06, 'Matt Calabrese' via ISO C++ Standard -

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard -

Post by 'CJ Johnson' via ISO C++ Standard - Future Proposals
Hi everyone! I'd really appreciate feedback on this EWG/CWG
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.

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.

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmy9uUrNp4yAX7f%3DOc4p%3DqVqeS0fN11bFVBwtaZ%3Dbu%3DdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/790ba68a-bdbd-48bc-8f84-d71a44ba5c77%40isocpp.org?utm_medium=email&utm_source=footer>
.

'CJ Johnson' via ISO C++ Standard - Future Proposals

2018-11-29 14:30:50 UTC

Permalink

Sounds good to me! Added to the draft :)

Post by 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.
On Wed, 28 Nov 2018 at 16:46, 'CJ Johnson' via ISO C++ Standard - Future

Post by 'CJ Johnson' via ISO C++ Standard - Future Proposals
Right now this is left as an open question. Should I add a potential
answer? What do you think the semantics should be?

Post by Richard Smith
On Wed, 28 Nov 2018 at 09:06, 'Matt Calabrese' via ISO C++ Standard -

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
On Wed, Nov 28, 2018 at 11:56 AM 'CJ Johnson' via ISO C++ Standard -

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.

Post by 'Matt Calabrese' via ISO C++ Standard - Future Proposals
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmy9uUrNp4yAX7f%3DOc4p%3DqVqeS0fN11bFVBwtaZ%3Dbu%3DdQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.