This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
1359. Add<tuple> and <utility> to freestanding implementations
Section: 16.4.2.5 [compliance] Status: NAD Submitter: BSI Opened: 2010-08-25 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [compliance].
View all issues with NAD status.
Discussion:
Addresses GB-56
The <utility> header provides support for several important C++ idioms with move, forward and swap. Likewise, declval will be frequently used like a type trait. In order to complete cycles introduced by std::pair, the <tuple> header should also be made available. This is a similarly primitive set of functionality, with no dependency of a hosted environment, but does go beyond the minimal set of functionality otherwise suggested by the freestanding libraries.
Alternatively, split the move/forward/swap/declval functions out of <utility> and into a new primitive header, requiring only that of freestanding implementation.
[ Summary of Rapperswil discusions ]
The preference of the meeting was to extract the rvalue-reference related utilities and swap into a freestanding header, but there was no clear preference for a name. Howard suggested simply dropping them into <type_traits> as both these utilities and type traits are used pretty much everywhere in the library implementation, it is the most convenient place to keep them (from an implementer's perspective).
Poll: Two-way: New header for forward, move, swap, move_with_noexcept and declval vs. calling out forward, move, swap, move_with_noexcept and declval as freestanding explicitly? SF new header: 4 WF new header: 3 WF call out as freestanding: 1 SF call out as freestanding: 2 Alisdair: Willing to write up both solutions, give us some time to think on it. Action: Need an issue and proposed wording for GB 56 - Alisdair to draft both options as in the last poll.
[ Resolution proposed by ballot comment ]
Add
<utility>and<tuple>to table 15, headers required for a free-standing implementation.
[ 2010-Batavia: ]
Closed as NAD, reversing the decision at Rapperswil.
The consensus was that any freestanding implementation is going to feel compelled to offer the important features of <utility> even if we do not make them a freestanding requirement; breaking out additional small headers may have additional costs at compile time, and while the critical move-related functions could migrate to <type_traits>, the header name is far from appealing; adding the whole of <utility> starts to drag in dependencies on <tuple> and <memory>, so we prefer to place the burden of slicing or supporting this whole header on free-standing vendors.
Proposed resolution:
Rationale:
No consensus for a change at this time.
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