Proposed resolution:

This resolution is relative to N4659.

1. Edit [futures.promise], class template promise synopsis, as indicated:

   template<class R> 
   class promise {
   public:
     promise();
     template <class Allocator>
       promise(allocator_arg_t, const Allocator& a);
     […]
   };
   template <class R>
     void swap(promise<R>& x, promise<R>& y) noexcept;
   template <class R, class Alloc>
     struct uses_allocator<promise<R>, Alloc>;
   

   […]

   template <class R, class Alloc>
     struct uses_allocator<promise<R>, Alloc>
       : true_type { };
   

   -3- Requires: Alloc shall be an Allocator ([allocator.requirements]).

   promise();
   template <class Allocator>
     promise(allocator_arg_t, const Allocator& a);
   

   -4- Effects: constructs a promise object and a shared state. The second constructor uses the allocator a to allocate memory for the shared state.

[ 2019-06-03 ]

Jonathan observes that this resolution conflicts with 2095.

[ 2018-1-26 issues processing telecon ]

Status to 'Open'; Billy to write a paper.

[ 28-Nov-2017 Mailing list discussion - set priority to P2 ]

Lots of people on the ML feel strongly about this; the suggestion was made that a paper would be welcomed laying out the rationale for removing allocator support here (and in other places).

In Toronto Saturday afternoon LWG discussed LWG 2976 which finishes the job of removing allocator support from packaged_task. LWG confirmed that, despite the removal of packaged_task allocators "because it looks like std::function" was incorrect, they wanted to keep the allocator removals anyway, in large part due to this resolution being a response to an NB comment.

If we don't want the type erased allocator situation at all, then we should remove them from the remaining place they exist in <future>, namely, in promise.

This change also resolves potential implementation divergence on whether allocator::construct is intended to be used on elements constructed in the shared state, and allows the emplace-construction-in-future paper, P0319, to be implemented without potential problems there.