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
>