On Jan 9, 2020, at 4:30 PM, Jens Maurer <Jens.Maurer_at_[hidden]> 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