Date: Sat, 8 May 2021 22:03:03 +0100
On Sat, 8 May 2021, 21:14 Nevin Liber, <nevin_at_[hidden]> wrote:
> On Sat, May 8, 2021 at 2:50 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Sat, 8 May 2021, 20:32 Nevin Liber, <nevin_at_[hidden]> wrote:
>>
>>> On Sat, May 8, 2021 at 2:18 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>>>
>>>>
>>>> I think adding std::unreachable(); after the assertion would work for
>>>> that purpose.
>>>>
>>>
>>> If I'm reading it correctly, the paper says that unreachable is not
>>> allowed in a constant expression (because calling it is UB).
>>>
>>
>> It means that unreachable() cannot be called during constant evaluation.
>> It is allowed in a constexpr function as long as it's not reached. That's
>> the same as falling off the end of a function, isn't it? I don't think it
>> changes anything.
>>
>> During constant evaluation, if you reach the end of a non-void function
>> it's an error. Reaching a call to unreachable would be the same.
>>
>>
>> That is a breaking change for calling assert in a constexpr context
>>> [assertions.assert]. And even if we fix the one in the standard, how can
>>> users write their own?
>>>
>>
>>
>> No, because I'm not suggesting adding it to assert. I said add it after
>> the assertion, i.e. in the function containing the assertion.
>>
>
> For assert(false), sure they can, although now that would require users
> to change code where they have already documented the code is unreachable.
>
Yes, I think that's ok. More than ok, I think that's good. They documented
it using something that is explicitly specified to expand to nothing when
NDEBUG is defined. That has no more weight than a comment saying "//
unreachable".
Compilers might choose to interpret assert(false) in some special way (just
like they sometimes interpret comments like "// FALLTHRU" to suppress
warnings about falling through to the next case statement). But I think the
only realistic approach we can take in the standard is to say the assert
has no special meaning, and that adding "std::unreachable();" would be
needed.
> What about assert(b) when NDEBUG is not defined? JF said that would
> become an unconditional call to std::unreachable, but calling
> std::unreachable invokes UB. From the paper: "The author feels that the
> best way is to make the behavior of std::unreachable() be undefined."
>
As he already said, he made no suggestion to change assert.
I think assert is entirely unrelated to this proposed feature. The feature
is about falling off the end of a function, not changing what assert does.
> On Sat, May 8, 2021 at 2:50 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Sat, 8 May 2021, 20:32 Nevin Liber, <nevin_at_[hidden]> wrote:
>>
>>> On Sat, May 8, 2021 at 2:18 PM Jonathan Wakely <cxx_at_[hidden]> wrote:
>>>
>>>>
>>>> I think adding std::unreachable(); after the assertion would work for
>>>> that purpose.
>>>>
>>>
>>> If I'm reading it correctly, the paper says that unreachable is not
>>> allowed in a constant expression (because calling it is UB).
>>>
>>
>> It means that unreachable() cannot be called during constant evaluation.
>> It is allowed in a constexpr function as long as it's not reached. That's
>> the same as falling off the end of a function, isn't it? I don't think it
>> changes anything.
>>
>> During constant evaluation, if you reach the end of a non-void function
>> it's an error. Reaching a call to unreachable would be the same.
>>
>>
>> That is a breaking change for calling assert in a constexpr context
>>> [assertions.assert]. And even if we fix the one in the standard, how can
>>> users write their own?
>>>
>>
>>
>> No, because I'm not suggesting adding it to assert. I said add it after
>> the assertion, i.e. in the function containing the assertion.
>>
>
> For assert(false), sure they can, although now that would require users
> to change code where they have already documented the code is unreachable.
>
Yes, I think that's ok. More than ok, I think that's good. They documented
it using something that is explicitly specified to expand to nothing when
NDEBUG is defined. That has no more weight than a comment saying "//
unreachable".
Compilers might choose to interpret assert(false) in some special way (just
like they sometimes interpret comments like "// FALLTHRU" to suppress
warnings about falling through to the next case statement). But I think the
only realistic approach we can take in the standard is to say the assert
has no special meaning, and that adding "std::unreachable();" would be
needed.
> What about assert(b) when NDEBUG is not defined? JF said that would
> become an unconditional call to std::unreachable, but calling
> std::unreachable invokes UB. From the paper: "The author feels that the
> best way is to make the behavior of std::unreachable() be undefined."
>
As he already said, he made no suggestion to change assert.
I think assert is entirely unrelated to this proposed feature. The feature
is about falling off the end of a function, not changing what assert does.
Received on 2021-05-08 16:03:22