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: 99 [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.
The spec for hash<optional<T>> doesn't say anything about disengaged objects, so 3.27 [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>.
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.
Confirmed that this issue is resolved in the current Library Fundamentals working paper.
This wording is relative to N3691.
Add to 99 [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) .