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
>