This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 5.11 [fund.ts::optional.hash] Status: Resolved Submitter: Jonathan Wakely Opened: 2013-10-03 Last modified: 2015-10-26
Priority: Not Prioritized
View all issues with Resolved status.
Discussion:
Addresses: fund.ts
The spec for hash<optional<T>> doesn't say anything about disengaged objects, so 3.65 [defns.undefined] would imply it's undefined behaviour, but that's very unhelpful to users.
If hashing disengaged optional objects is undefined there should be a Requires, otherwise there should be some statement saying it's OK. It would be possible to specify the value, e.g. saying it returns the same value as something like std::hash<void*>()(nullptr), but leaving it unspecified would permit users to specialize hash<optional<UserDefinedType>> so that the hash value for a disengaged object is distinct from any value returned by hash<UserDefinedType>.[2014-06-06 pre-Rapperswill]
This issue has been reopened as fundamentals-ts.
[2014-06-07 Daniel comments]
This issue should be set to Resolved, because the wording fix is already applied in the last fundamentals working draft.
[2014-06-16 Rapperswill]
Confirmed that this issue is resolved in the current Library Fundamentals working paper.
Proposed resolution:
This wording is relative to N3691.
Add to 5.11 [fund.ts::optional.hash]/3
template <class T> struct hash<optional<T>>;[…]
-3- For an object o of type optional<T>, if bool(o) == true, hash<optional<T>>()(o) shall evaluate to the same value as hash<T>()(*o) otherwise it evaluates to an unspecified value.