This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

### 2470. Allocator's `destroy` function should be allowed to fail to instantiate

Section: 16.4.4.6 [allocator.requirements] Status: C++17 Submitter: Daniel Krügler Opened: 2015-03-22 Last modified: 2017-07-30

Priority: Not Prioritized

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with C++17 status.

Discussion:

This issue is a spin-off of issue LWG 2447: It focuses on the observation that 16.4.4.6 [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.

[2015-04-01 Library reflector vote]

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

Proposed resolution:

This wording is relative to N4296.

1. Change 16.4.4.6 [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.