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.

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

[
post San Francisco:
]

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

Recommend NAD.

[
Post Summit:
]

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

[
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
19.14 [function.objects] does not mention hash< thread::id>
nor hash< error_code >, although their existence is
implied by 19.14.16 [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.

[
Batavia (2009-05):
]

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

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

[
2009-07 Frankfurt
]

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

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

[
2009-10 Santa Cruz:
]

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

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

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

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

[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]