Proposed resolution:

This wording is relative to N3936.

1. Change [tuple.general] p2, header <tuple> synopsis, as indicated

   […]
   // 20.4.2.5, tuple helper classes:
   template <class T> class tuple_size; // undefined
   […]
   

2. Change [tuple.helper] as indicated

   […]
   template <class T> struct tuple_size { };
   […]
   

[ 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

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

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

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