Why aren't parts of the Concurrency TS going i

问题:

According to Michael Wong the Concurrency TS is not going in, despite complete, apparently

Although there is implementation experience, it was just approved and is too fresh to be voted to be added to C++17.

My favourite proposal was originally in N3327 but I first read of it in N3857/N3784 and had expected it for C++14. futures has had and implementation of .then() in Boost 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 .get() is a necessity and seemed to been decided upon since early-2014 when N3865 ('More Improvements to std::future') talked as if .then() was a given. Which means even with 5 years since N3327 first raised a .then() due to 'streamlining' any well thought out, discussed and implemented proposal is blocked by discussions going on that is tangential to it.

It is now going to be 2020 before it will ship.

Is the Concurrency TS a whole or nothing proposal? And if so why?

回答1:

It is now going to be 2020 before it will ship.

It's shipping now. Just not in the C++ standard itself.

You shouldn't think of a TS as some kind of fictional document. It's a real thing, and many vendors implement TS's. Microsoft and libc++ have support for the FileSystem TS, for example.

With C++17 feature complete, compiler and standard library vendors have their hands full implementing those features. Not to mention the Concepts TS and so forth. So it's not surprising that the Concurrency TS isn't their highest priority.

As for why parts of Concurrency weren't added to C++17, the minutes of the Jacksonville meeting show that SG1 (the study group for concurrency issues) specifically proposed adding Parallelism TS to the standard, but did not do so for Concurrency TS. So they apparently felt that Concurrency TS was not ready to be added to the standard library, even partially.