Here's a draft. Could you please incorporate it? I did not yet run it
through an html checker.

I believe we were also asked to address questions about locales?

<h>Notable design decisions.</h>
<p>
A more detailed rationale for many of the decisions made here is given in
<a href="http://wg21.link/p1875">P1875</a>. Here we quickly summarize
design decisions leading
to this proposal. These are generally motivated by the desire to produce a
much simpler,
more easily implementable specification. Except for the last two, these
have been stable
since the original SG1 discussion. All were part of the proposal during the
final EWG
discussion.
<ul>
<li> This is a language, not library, proposal.
Passing lambda expressions to a "run this as a transaction" function was
not well-liked, and has
issues with varargs access. An RAII-based library facility was considered,
but also disliked by
SG1, this time, among other issues, because it waas unclear what this would
mean if the RAII
object was not stack-allocated.</li>
<li> We want to leave a lot implementation-defined for the TS, to encourage
implementations,
and support experimentation. We do not want to again end up with a TS that
is difficult to
implement usefully, and thus fails to attract implementations.</li>
<li> We want to focus on simple implementations that are based in hardware
transactional memory,
and/or use the
trivial global lock implementation. We expect HTM implementations that fall
back on a global
lock to dominate in practice, at least initially. We want to allow more
elaborate implementations
based on software transactional memory but, unlike the current TS, we do
not want to require
such elaborate implementations.</li>
<li> There is no support for explicitly declaring transaction-safety. This
is a major simplification
over the current Technical Specification. This does not matter for HTM or
gloabl lock implementations,
which do not need to instrument code. It does make it more difficult to
extract good performance
from software transctional memory implementations, but there is agreement
that the simplification is worth
the trade-off.</li>
<li> Exceptions may not escape from transactions. This dodges many
complicated issues about whether
transactions should commit or abort and, in the latter case, how exception
objects themselves survive
transaction aborts.</li>
<li> The "atomic do {...}" syntax. This was the most natural syntax we
(mostly EWG) could come up with that
appears to be easily parseable, and does not require a new keyword. It was
"atomic {...}" during SG1 discussions.
"atomic do" reflects a non-unanimous consensus in EWG.</li>
<li> Allow <code>malloc (and hence non-escaping exceptions, and much more
of the standard library) inside transactions.
This was a recent change, but preceded the last EWG discussion. We
previously thought that we could get by with
very restricted transactions, so long as they were sufficiently general to
implement N-way compare_exchange.
Closer examination by SG5 determined that was problematic since the load
operations preceding the compare_exchange
transaction would also need to be transactions, making them expensive, at
least without heroic implementation
effort. Thus we concluded that it was desirable to again allow much of the
standard library inside
transactions. (Also discussed in more detail in P1875, but more as an open
issue.)</li>
</ul>

On Mon, Jun 28, 2021 at 6:17 PM Hans Boehm <boehm_at_[hidden]> wrote:

> Will do. Let's go ahead and cancel the meeting.
>
> On Mon, Jun 28, 2021, 1:01 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
>
>> On 28/06/2021 04.48, Hans Boehm via SG5 wrote:
>> > We have a meeting scheduled for Tuesday. I don't think anything has
>> happened in the interim that really requires discussion. Unless someone
>> else has an agenda item, I suggest we cancel again. (If you received an
>> earlier pair of cancel/reinstate requests from Google calendar, my
>> apologies.)
>> >
>> > We have a scheduled meeting with LEWG Aug 17th at 10a.m. We need a
>> small update to P2066 before then, at Bryce's (LEWG Chair) request,
>> basically summarizing past decisions. Jens- Should I slightly expand what I
>> wrote in the May 25 message? Can you incorporate it then, so we have
>> something in the July mailing?
>>
>> If you have something that I can then cut/paste into P2066, that would be
>> most
>> helpful.
>>
>> Jens
>>
>>