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.