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.

2333. [fund.ts] Hashing disengaged optional<T> objects

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.

  1. 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.