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] <mailto: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] <mailto:sg5-bounces_at_[hidden]>> On Behalf Of Victor Luchangco via SG5
> Sent: Monday, September 28, 2020 6:54 PM
> To: sg5_at_[hidden] <mailto:sg5_at_[hidden]>
> Cc: Victor Luchangco <victor.luchangco.work_at_[hidden] <mailto: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] <mailto:SG5_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5 <https://lists.isocpp.org/mailman/listinfo.cgi/sg5>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5