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.

2026. hash should be std qualified for unordered container

Section: 23.5 [unord] Status: NAD Submitter: Pete Becker Opened: 2011-02-07 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [unord].

View all issues with NAD status.

Discussion:

Tom Plum pointed out to me that there's an apparent inconsistency in the std:: qualification of template names in the unordered containers:

 template <class Key,
           class T,
           class Hash = hash<Key>,
           class Pred = std::equal_to<Key>,
           class Alloc = std::allocator<std::pair<const Key, T> > >
   class unordered_map;

Is there a reason that hash is not qualified with std::? TR1 also does not use std:: here.

[ 2011-02-07 Chris Jefferson adds: ]

I assumed (I might be wrong) it is because hash is designed to be a customisation point, like swap.

[ 2011-02-07 Howard Hinnant adds: ]

I think this is incorrect. We mean std::hash, though clients are free to specialize std::hash on user-defined types. With the possible exception of begin/end (which I'm not sure if we've settled that), swap is the only intended customization point (look up a function by ADL) in the std:: lib.

[ 2011-02-24 Chris Jefferson adds: ]

I recommend NAD, due to 16.4.2.2 [contents] p3:

Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified as ::std::x, unless explicitly described otherwise. For example, if the Effects section for library function F is described as calling library function G, the function ::std::G is meant.

[2011-02-25 Reflector discussion]

Moved to Tentatively NAD after 5 votes.

Proposed resolution: