Proposed resolution:

This wording is relative to N3936.

Change [unord.hash] p1 as indicated:

The unordered associative containers defined in 23.5 use specializations of the class template hash as the default hash function. For all object types Key for which there exists a specialization hash<Key>, and for all integral and enumeration types (7.2) Key, the instantiation hash<Key> shall: […]

[ 2015-05, Lenexa ]

STL: the new PR is very simple and could resolve that nicely
MC: the older PR is rather longish

• anybody have any objections to this approach?

• what people want to have as a status?

STL: I want to have Ready
MC: move to ready: in favor: 13, opposed: 0, abstain: 4

[ 2014-05-06 Geoffrey Romer suggests alternative wording ]

Previous resolution from Daniel [SUPERSEDED]:

This wording is relative to the FDIS.

Change [unord.hash] p2 as indicated:

template <> struct hash<bool>;
template <> struct hash<char>;
[…]
template <> struct hash<long double>;
template <class T> struct hash<T*>;

-2- Requires: the template specializations shall meet the requirements of class template hash ([unord.hash])The header <functional> provides definitions for specializations of the hash class template for each cv-unqualified arithmetic type. This header also provides a definition for a partial specialization of the hash class template for any pointer type. The requirements for the members of these specializations are given in sub-clause [unord.hash].

[ 2012, Kona ]

Move to Open.

Agreed that it's a real issue and that the proposed wording fixes it. However, the wording change is not minimal and isn't consistent with the way we fixed hash wording elsewhere.

Alisdair will provide updated wording.

According to the header <functional> synopsis [function.objects] and to the explicit description in [unord.hash] class template hash specializations shall be provided for all arithmetic types that are not extended integer types. This is not explicitly mentioned, but neither the list nor any normative wording does include them, so it follows by implication.

What are the reasons that extended integer types are excluded? E.g. for numeric_limits corresponding specializations are required. I would expect that an unordered_map with key type std::uintmax_t would just work, but that depends now on whether this type is an extended integer type or not.

This issue is not asking for also providing specializations for the cv-qualified arithmetic types. While this is surely a nice-to-have feature, I consider that restriction as a more secondary problem in practice.

The proposed resolution also fixes a problem mentioned in 2109 in regard to confusing requirements on user-defined types and those on implementations.