A default-constructed thread is documented as being non-joinable: Ok, I can't join it. So what can I do with it? Not a whole heck of a lot aside from comparing it to other threads.
This brings me some thoughts. The thread class is non-copyable (which is fine by me) and also it has an operator==. I think these two things contradict each other. When defining an equal operator, we are actually defining semantics for copying: copying an object will result in a second object that will be equal, in terms of operator==, to the first object. Defining an equal operator means that objects can be equal, or in other works, they are a copies of the same value! To strengthen my point, I'll say that this not just theory, it's also partially been done in practice, here in the thread class. The no-parameters constructor is just that - it copies the current thread. The result of the no-parameters constructor is a copy of the object representing the current thread. Copies can be done! IMHO, there are two possibilities: The first is to declare that threads are in fact copyable and providing full support for that (copy constructor, etc.). And again, copying them means creating a second object that is 'opeator==' equal to the first. The second possibility is to insist that threads are non-copyable. That means that the no-parameters constructor and the equal opeator have to go, because they contradict this concept. But do we loose functionality if we erase those? If we agree that the only use for them is the ablity to write some like like: bool is_current_thread(const thread &t) { return t == thread(); } then it would be much better to have a member function bool thread::is_current() const; that will do just that. It's much more accurate and expressive to use ' if (some_thread.is_current())' then to use 'if (some_thread == thread())'. I hope I was persuasive, Yuval