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.