On 10/01/2020 15.48, Michael L. Scott wrote:
> On Jan 9, 2020, at 4:30 PM, Jens Maurer <Jens.Maurer_at_[hidden] <mailto: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.

Yes.

>> 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.

It probably hasn't anything to do with that question.

Jens