Thanks. I agree that "undefined behavior" is better.

- Victor

On Wed, Sep 30, 2020 at 7:47 PM Michael Spear via SG5 <sg5_at_[hidden]>
wrote:

> I agree.
>
> - Mike
>
> On Wed, Sep 30, 2020 at 6:48 PM Michael L. Scott via SG5 <
> sg5_at_[hidden]> wrote:
>
>> I agree that undefined behavior is better.
>>
>> - Michael
>>
>> On Sep 30, 2020, at 6:23 PM, Hans Boehm via SG5 <sg5_at_[hidden]>
>> wrote:
>>
>> I think in this case the concern is less with the formal requirements
>> imposed by implementation-defined vs. undefined behavior, than it is on the
>> signal we give to programmers. Although "implementation defined" is allowed
>> to mean "undefined" in specific implementations, it implies that it is a
>> reasonable feature to use if you happen to know something about the
>> implementations you're using. So the question is really whether we want
>> implementations to specify that their "atomic do" is really atomic_commit
>> or atomic_cancel, and then have programmers rely on that.
>>
>> My sense is no. It would have some experimentation benefit. But it would
>> generate a body of seemingly reasonable code with very different semantics
>> on different implementations. You wouldn't be able to read the code without
>> asking about the target implementation. That seems like a bad thing.
>>
>> I actually don't think it makes sense for implementations to implement
>> "atomic do" as atomic_cancel, since they would have to reinvent all sorts
>> of other rules about escaping exceptions. Thus we could conceivably leave
>> it implementation-defined with strong implementation guidance that if throw
>> is allowed, it should be implemented as atomic_noexcept or atomic_commit.
>> That should avoid the semantic ambiguity. But I'm still not sure it's a
>> good idea.
>>
>> On Wed, Sep 30, 2020 at 10:02 AM Michael Hava via SG5 <
>> sg5_at_[hidden]> wrote:
>>
>>> The functional difference would be: A program with
>>> *implementation-defined* semantics is always *well-formed* and the
>>> behavior of the implementation must be *documented*.
>>>
>>>
>>>
>>> *From:* SG5 <sg5-bounces_at_[hidden]> *On Behalf Of *Victor
>>> Luchangco via SG5
>>> *Sent:* Monday, September 28, 2020 6:54 PM
>>> *To:* sg5_at_[hidden]
>>> *Cc:* Victor Luchangco <victor.luchangco.work_at_[hidden]>
>>> *Subject:* Re: [SG5] Points raised on EWG reflector
>>>
>>>
>>>
>>> What is the functional difference between "undefined behavior" (I assume
>>> this is what UB stands for) and "implementation defined"?
>>>
>>>
>>>
>>> Presumably, a particular implementation can implement "undefined
>>> behavior" however it likes, and in particular, it can do so in a
>>> predictable
>>>
>>> and understandable way. Does saying that behavior is
>>> implementation-defined create an onus on implementors to actually give
>>> well-defined
>>>
>>> semantics to a feature? (I agree that we do not want to create any such
>>> onus.)
>>> --
>>> SG5 mailing list
>>> SG5_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>>>
>> --
>> SG5 mailing list
>> SG5_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>>
>>
>> --
>> SG5 mailing list
>> SG5_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>