This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.
Section: 19.14.18 [unord.hash] Status: C++17 Submitter: Daniel Krügler Opened: 2011-12-16 Last modified: 2019-01-01
View other active issues in [unord.hash].
View all other issues in [unord.hash].
View all issues with C++17 status.
According to the header <functional> synopsis 19.14 [function.objects] and to the explicit description in 19.14.18 [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.
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.
[2014-05-06 Geoffrey Romer suggests alternative wording]
Previous resolution from Daniel [SUPERSEDED]:
This wording is relative to the FDIS.
Change 19.14.18 [unord.hash] p2 as indicated:template <> struct hash<bool>; template <> struct hash<char>; […] template <> struct hash<long double>; template <class T> struct hash<T*>;
Requires: the template specializations shall meet the requirements of class template hash (19.14.18 [unord.hash]).
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
This wording is relative to N3936.
Change 19.14.18 [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 enumeration types (7.2) Key, the instantiation hash<Key> shall: […]