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.

### 889. `thread::id` comparisons

Section: 32.4.3.2 [thread.thread.id] Status: Resolved Submitter: Lawrence Crowl Opened: 2008-09-15 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [thread.thread.id].

View all issues with Resolved status.

Discussion:

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.

[ 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 N2723 already has `hash<thread::id>` (20.14 [function.objects], 20.14.19 [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 20.14 [function.objects] does not mention `hash< thread::id>` nor `hash< error_code >`, although their existence is implied by 20.14.19 [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 Editorial Resolved, addressed by 1182 have been removed. Set to Tentatively NAD Editorial Resolved. ]

Rationale:

Solved by 1182.

Proposed resolution:

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

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

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

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

Add template specialization below class definition in 32.4.3.2 [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 32.4.3.2 [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 32.4.3.2 [thread.thread.id]

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

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