On Tue, Sep 22, 2020 at 4:44 PM Michael L. Scott via SG5 <
sg5_at_[hidden]> wrote:

> On Sep 22, 2020, at 12:26 PM, Hans Boehm via SG5 <sg5_at_[hidden]>
> wrote:
>
> > EWG reflector discussions raised another couple of points, which I had
> lost track of:
> >
> > Tony Van Eerd pointed out that we probably want exceptions escaping from
> a transaction to be UB rather than implementation defined, since the
> semantics have been regularly debated. We don't really want some
> implementations supporting commit, and others abort semantics. Code just
> shouldn't rely on that. I tend to agree with that observation.
>
> I agree as well.
>

Sorry to jump on this so late:

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.)


> > There was also discussion of somehow providing a capture list for
> transactions, as in lambda's. I'm less confident I understand that proposal.
>
> Interesting. Perhaps the idea is that the code should explicitly document
> what it is that the transaction touches? That’s a tempting idea, but
> probably not as useful as one might hope for linked data structures, where
> what may be modified is the _reach_ of the capture.
>
>
I agree that this is interesting, but it raises issues that I think it's
better to avoid for now, if we can.

- Victor

- Michael
>
> > Hans
> > --
> > 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
>