Attendees:

Hans Boehm, Nathan Burgers, Victor Luchangco, Jens Maurer, Michael Scott,
Mike Spear

Jens provided p2066r3, which is in the currently unpublished mailing.

Mike Spear provided a draft of a paper about requiring allocation support.

We discussed functions allowed in atomic blocks. We're basically happy with
the list, but unsure that the current wording is sufficient.

Some general discussion about addition of allocation, though we postponed
discussion of Mike's paper.

If we add malloc, we will want containers, uniqe_ptr, String, etc.

Jens - Want to keep this non-challenging for implementers.

Victor - Maybe suggest an approach for adding malloc, but don't require it.

Jens - Wouldn't really be part of the specification.

Hans - If we did add allocation, would implementation defined behavior for
out-of-memory be OK?

Consensus in favor. (But no consensus to require allocation. That remains
to be discussed.)

How important is out-of-memory handling?

Jens and Hans suggested that it's commonly not critical, beyond error
reporting. And this is a sore spot in other parts of the standard as well.

Could we call std::terminate?

We're still in transaction, which makes this tricky.

Continued consensus to stick with implementation defined behavior for
out-of-memory if we add allocation.

Jens - How do we proceed?

Consensus: Give ourselves a month to look over and think about 2066R3.
Alert SG1 to the changes. Aim to vote it out of SG5 next time, and put it
back on EWG's plate.

Next meeting:

Oct. 20, 8 a.m. PDT, 11 a.m EDT (I suspect Europe and the US are
out-of-sync with respect to daylight time?)

Agenda for next meeting:
P2066R3, aiming for a straw poll
Discuss Mike Spear's paper proposing allocation support.