Proposed resolution:

Remove the following prototype from the synopsis in [function.objects]:

template <> struct hash<std::thread::id>;

Add to [thread.threads], p1 Header <thread> synopsis:

template <class T> struct hash;
template <> struct hash<thread::id>;

Add template specialization below class definition in [thread.thread.id]

template <>
struct hash<thread::id> : public unary_function<thread::id, size_t> {
   size_t operator()(thread::id val) const;
};

Extend note in p2 [thread.thread.id] with second sentence:

[Note: Relational operators allow thread::id objects to be used as keys in associative containers. hash template specialization allows thread::id objects to be used as keys in unordered containers. — end note]

Add new paragraph to end of [thread.thread.id]

template <> struct hash<thread::id>;

An explicit specialization of the class template hash ([unord.hash]) shall be provided for the type thread::id.

Rationale:

Solved by 1182.

[ 2010-02-09 Objections to moving this to NAD EditorialResolved, addressed by 1182 have been removed. Set to Tentatively NAD EditorialResolved. ]

[ 2010-02-09 Moved from Ready to Open: ]

Issue 1182 is not quite a superset of this issue and it is controversial whether or not the note:

hash template specialization allows thread::id objects to be used as keys in unordered containers.

should be added to the WP.

[ 2009-11-13 The proposed wording of 1182 is a superset of the wording in this issue. ]

[ 2009-10 Santa Cruz: ]

Add a strike for hash<thread::id>. Move to Ready

[ 2009-07-28 Alisdair provided wording, moved to Review. ]

[ 2009-07 Frankfurt ]

Decided we want to move hash specialization for thread_id to the thread header. Alisdair to provide wording.

[ 2009-05-24 Alisdair adds: ]

I do not believe this is correct. thread::id is explicitly documents as a nested class, rather than as an unspecified typedef analogous to an iterator. If the intent is that this is not implemented as a nested class (under the as-if freedoms) then this is a novel form of standardese.

[ Batavia (2009-05): ]

Howard observes that thread::id need not be a nested class; it could be a typedef for a more visible type.

[ Post Summit, Alisdair adds: ]

The recommendation for LWG-889/UK-324 is NAD, already specified.

It is not clear to me that the specification is complete.

In particular, the synopsis of <functional> in [function.objects] does not mention hash< thread::id> nor hash< error_code >, although their existence is implied by [unord.hash], p1.

I am fairly uncomfortable putting the declaration for the thread_id specialization into <functional> as id is a nested class inside std::thread, so it implies that <functional> would require the definition of the thread class template in order to forward declared thread::id and form this specialization.

It seems better to me that the dependency goes the other way around (<thread> will more typically make use of <functional> than vice-versa) and the hash<thread::id> specialization be declared in the <thread> header.

I think hash<error_code> could go into either <system_error> or <functional> and have no immediate preference either way. However, it should clearly appear in the synopsis of one of these two.

Recommend moving 889 back to open, and tying in a reference to UK-324.

[ Post Summit: ]

Recommend to close as NAD. For POSIX, see if we need to add a function to convert pthread_t to integer.

[ post San Francisco: ]

Howard: It turns out the current working paper N2723 already has hash<thread::id> ([function.objects], [unord.hash]). We simply overlooked it in the meeting. It is a good thing we voted in favor of it (again). :-)

Recommend NAD.

[ San Francisco: ]

Would depend on proposed extension to POSIX, or non-standard extension. What about hash? POSIX discussing op. POSIX not known to be considering support needed for hash, op.

Group expresses support for putting ids in both unordered and ordered containers.

Addresses UK 324

The thread::id type supports the full set of comparison operators. This is substantially more than is required for the associative containers that justified them. Please place an issue against the threads library.