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>