On Sep 22, 2020, at 12:26 PM, Hans Boehm via SG5 <sg5@lists.isocpp.org> 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@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
--
SG5 mailing list
SG5@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg5