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.
Section: 22.4.1 [tuple.general] Status: NAD Submitter: Nevin Liber Opened: 2014-10-10 Last modified: 2018-06-23
Priority: Not Prioritized
View all other issues in [tuple.general].
View all issues with NAD status.
Discussion:
In 22.4.1 [tuple.general] paragraph 2, the unspecialized std::tuple_size is undefined. It would be a lot more useful with SFINAE if it were defined as an empty struct; that way, it can be used with enable_if for determining whether or not it is valid to use tuple_size, tuple_element and get on the corresponding data structure.
[2014-11 Urbana]
Moved to LEWG 42.
This request goes beyond simply making an API respond well to SFINAE, but coupling that with an implication for other tuple APIs. The proper place for such design discussions is LEWG.
[2017-02 in Kona, LEWG recommends NAD]
We believe there are other ways to achieve the same results (at least for all of the use cases we could see). We invite Nevin to provide more details / motivations if this is necessary, not just helpful in a limited number of cases. If the dr is raised, variant_size should be considered for the same change as well.
[2017-06-02 Issues Telecon]
It's unclear what benefit this change would have, but making it complete would have very undesirable interactions with structured bindings. The current Core wording for structured bindings depends on tuple_size being an incomplete type.
Resolve as NAD
Proposed resolution:
This wording is relative to N3936.
Change 22.4.1 [tuple.general] p2, header <tuple> synopsis, as indicated
[…] // 20.4.2.5, tuple helper classes: template <class T> class tuple_size;// undefined[…]
Change 22.4.7 [tuple.helper] as indicated
[…]
template <class T> struct tuple_size { };
[…]