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'sdestroy 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(i): 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
constructmember may be called. If a type cannot be used with a particular allocator, the allocator class or the call toconstructmay 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.
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
constructordestroymember s may be called. If a type cannot be used with a particular allocator, the allocator class or the call toconstructordestroymay fail to instantiate.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4