title: Why must one call join() or detach() before thread destruction?
body: <p>I don't understand why when an <code>std::thread</code> is destructed it must be in join() or detach() state.</p>
  
  <p>Join waits for the thread to finish, and detach doesn't. 
  It seems that there is some middle state which I'm not understanding.
  Because my understanding is that join and detach are complementary: if I don't call join() than detach() is the default.</p>
  
  <p>Put it this way, let's say you're writing a program that creates a thread and only later in the life of this thread you call join(), so up until you call join the thread was basically running as if it was detached, no?</p>
  
  <p>Logically detach() should be the default behavior for threads because that is the definition of what threads are, they are parallelly executed irrespective of other threads.</p>
  
  <p>So when the thread object gets destructed why is terminate() called? Why can't the standard simply treat the thread as being detached?</p>
  
  <p>I'm not understanding the rationale behind terminating a program when either join() or detached() wasn't called before the thread was destructed. What is the purpose of this?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>I recently came across this. Anthony Williams states in his book, Concurrency In Action, "One of the proposals for C++17 was for a joining_thread class that would be similar to std::thread, except that it would automatically join in the destructor much like scoped_thread does. This didn’t get consensus in the committee, so it wasn’t accepted into the standard (though it’s still on track for C++20 as std::jthread)..."</p>