On Jan 9, 2020, at 4:30 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

On 09/01/2020 22.04, Michael L. Scott via SG5 wrote:
Regarding what is allowed within transactions, our current document (P1875R0) says:

...

In short, the only reason I can think of why an implementation might want to preclude calls to external functions is to avoid the need to check for the existence such calls.

The other problem is library functions: If we allow all functions
(even non-constexpr ones), we don't have an easy library spec marker
to indicate which functions are required to be supported and
which ones aren't. So, we'd need to specify library functions
individually or by broad clause numbers. For example, [atomics]
and [thread] functions are right out, but most of [utilities]
is ok... Except where exactly is setjmp / longjmp defined?

So, if I understand correctly, one reason to allow an implementation to say that only constexpr expressions are allowed is to avoid the hassle of listing which library functions are supported.

A slightly related issue:

Consider a "helpful" library implementation that does
special debug output (maybe in a file on the side) when
compiling certain algorithms in "debug" mode.  The library
might be third-party and not privy to the existence of TM.
However, its algorithms are constexpr, and it avoids
that debug output if std::is_constant_evaluated() is true.
That library has no way of avoiding the debug output =
possibly undefined behavior if it's called inside an atomic
block.

I’m not sure what this has to do with the question of how much to require implementations to support in atomic blocks.

Jens