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.4 [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.