Title
Dangling uses_allocator specialization for packaged_task
Status
c++20
Section
[futures.task][future.syn][futures.task.nonmembers]
Submitter
Tim Song

Created on 2017-06-13.00:00:00 last changed 38 months ago

Messages

Date: 2017-07-16.20:43:29

Proposed resolution:

This wording is relative to N4659.

  1. Modify [future.syn], header <future> synopsis, and [futures.task], class template packaged_task synopsis, as indicated:

    template <class R, class Alloc>
    struct uses_allocator<packaged_task<R>, Alloc>;
    
  2. Modify [futures.task.nonmembers] as indicated:

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

    -2- Requires: Alloc shall be an Allocator (20.5.3.5).

  3. Modify [futures.task.members]/5 as indicated:

    template <class F>
      packaged_task(F&& F);
    

    -2- Requires: […]

    -3- Remarks: […]

    -4- Effects: […]

    -5- Throws:

    — Aany exceptions thrown by the copy or move constructor of f., or

    — For the first version, bad_alloc if memory for the internal data structures could not be allocated.

    — For the second version, any exceptions thrown by allocator_traits<Allocator>::template rebind_traits<unspecified>::allocate.

Date: 2017-07-16.20:43:29

[ 2016-07, Toronto Saturday afternoon issues processing ]

Status to Ready

Date: 2017-06-15.00:00:00

[ 2017-06-26, Tim updates P/R to remove more dangling bits. ]

The additional point in the P/R effectively reverts the second part of the resolution of 2752.

The alternative resolution for this issue is, of course, to just revert the resolution of 2921. In that case 2245 needs to be reopened.

Date: 2017-07-15.00:00:00

[ 2017-06-26, Billy O'Neal reopens ]

I think 2921 was resolved in error. If promise<T> can have an allocator, there's no reason for packaged_task<T> to not have one. If we remove it from packaged_task we should remove it from promise as well.

Note that I am not objecting to removing allocator support here, I'm objecting to the "remove it because this looks like std::function" case. packaged_task has none of the std::function problems because the function inside a given packaged_task is not reassignable.

If LWG decides to remove allocator support here then there are more bits that need to be struck, e.g. [futures.task.members] (5.3).

Date: 2017-07-26.00:00:00

[ 2017-06-26 Moved to Tentatively Ready after 6 positive votes on c++std-lib. ]

Date: 2017-06-13.00:00:00

When LWG 2921 removed allocator support from packaged_task, it forgot to remove the uses_allocator partial specialization.

History
Date User Action Args
2021-02-25 10:48:01adminsetstatus: wp -> c++20
2017-11-13 19:01:36adminsetstatus: voting -> wp
2017-10-17 18:34:55adminsetstatus: ready -> voting
2017-07-16 20:43:29adminsetmessages: + msg9425
2017-07-16 20:43:29adminsetstatus: open -> ready
2017-06-26 19:30:49adminsetmessages: + msg9292
2017-06-26 18:48:59adminsetmessages: + msg9288
2017-06-26 18:48:59adminsetstatus: ready -> open
2017-06-26 17:35:23adminsetmessages: + msg9287
2017-06-26 17:35:23adminsetstatus: new -> ready
2017-06-13 19:25:09adminsetmessages: + msg9254
2017-06-13 00:00:00admincreate