title: Why aren't parts of the Concurrency TS going in C++17?
body: <p>According to <a href="https://wongmichael.com/category/c/" rel="nofollow">Michael Wong</a> the Concurrency TS is not going in, despite complete, apparently </p>
  
  <blockquote>
    <p>Although there is implementation experience, it was just approved and is too fresh to be voted to be added to C++17.</p>
  </blockquote>
  
  <p>My favourite proposal was originally in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3327.pdf" rel="nofollow">N3327</a> but I first read of it in N3857/<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3784.pdf" rel="nofollow">N3784</a> and had expected it for C++14. <code>futures</code> has had and implementation of <a href="http://www.boost.org/doc/libs/1_53_0/doc/html/thread/synchronization.html#thread.synchronization.futures.then" rel="nofollow">.then() in Boost</a> since 2013 and Microsoft has implemented a form of them in PPL so any issues will have been hit upon, discussed and corrected. An asynchronous version of <code>.get()</code> is a necessity and seemed to been decided upon since early-2014 when <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3865.pdf" rel="nofollow">N3865</a> ('More Improvements to std::future') talked as if <code>.then()</code> was a given. Which means even with 5 years since <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3327.pdf" rel="nofollow">N3327</a> first raised a <code>.then()</code> due to 'streamlining' any well thought out, discussed and implemented proposal is blocked by discussions going on that is tangential to it.</p>
  
  <p>It is now going to be 2020 before it will ship.</p>
  
  <p><strong>Is the Concurrency TS a whole or nothing proposal? And if so why?</strong> </p>