Title
Allocator's destroy function should be allowed to fail to instantiate
Status
c++17
Section
[allocator.requirements]
Submitter
Daniel Krügler

Created on 2015-03-22.00:00:00 last changed 89 months ago

Messages

Date: 2015-04-01.18:55:04

Proposed resolution:

This wording is relative to N4296.

  1. Change [allocator.requirements] p9 as indicated:

    -8- An allocator may constrain the types on which it can be instantiated and the arguments for which its construct or destroy members may be called. If a type cannot be used with a particular allocator, the allocator class or the call to construct or destroy may fail to instantiate.

Date: 2015-04-01.00:00:00

[ 2015-04-01 Library reflector vote ]

The issue has been identified as Tentatively Ready based on six votes in favour.

Date: 2015-03-22.00:00:00

This issue is a spin-off of issue LWG 2447: It focuses on the observation that [allocator.requirements] p9 (based on the numbering of working draft N4296) gives the template member construct more relaxations than the template member destroy:

An allocator may constrain the types on which it can be instantiated and the arguments for which its construct member may be called. If a type cannot be used with a particular allocator, the allocator class or the call to construct may fail to instantiate.

Construction and destruction of a type T are usually intimately related to each other, so it seems similarly useful to allow the destroy member to fail to instantiate for a possible sub-set of instantiation types.

History
Date User Action Args
2017-07-30 20:15:43adminsetstatus: wp -> c++17
2015-05-22 18:31:21adminsetstatus: ready -> wp
2015-04-01 18:55:04adminsetmessages: + msg7297
2015-04-01 18:55:04adminsetstatus: new -> ready
2015-03-22 18:38:21adminsetmessages: + msg7243
2015-03-22 00:00:00admincreate