Proposed resolution:

This wording is relative to N3691.

1. Add to [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.

[ 2014-06-16 Rapperswill ]

Confirmed that this issue is resolved in the current Library Fundamentals working paper.

[ 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-06 pre-Rapperswill ]

This issue has been reopened as fundamentals-ts.

Addresses: fund.ts

The spec for hash<optional<T>> doesn't say anything about disengaged objects, so [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>.