boost::future has a member function: boost::future::then, while std::future has no std::future::then.
This wonderful article shows how useful std::future::then would be.
Why is there no std::future::then in C++17?
Is it just an oversight, or because of other rationale behind?
.then support was incorporated into the Concurrency TS, which was finalized in early 2016. There was little practical experience with implementations of Concurrency TS, and with little time remaining until C++17 needed to be feature complete, it didn't make it in. Indeed, it was so late they didn't even bother proposing to add it to C++17.
Related
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?
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.
'Concepts lite' were already accepted as a TS and (example implementation) merged into GCC main branch, so the follow up question is will any concepts come predefined (like Sortable or Random_access_range)?
Where do I look for such predefined concepts?
Is the list at cppreference.com an acurate and exhaustive list?
Can I use them with the latest GCC trunk build?
Edit 1: Changed C++17 to TS due to concepts not being accepted into C++17.
There are no concepts defined in the Concepts TS (source: I wrote the Concepts TS).
It is neither an oversight nor mistake... The goal was to ship a pure language extension in the TS, allowing developers time to experiment with the new features before committing (an incredible amount of) time defining the concepts needed for the Standard Library.
The Ranges TS will define the concepts needed for the Standard Library.
GCC may ship with some concepts, but I have not heard of any concrete plans to do so. I have a library that defines many of the concepts (but not all) that appear in the Ranges TS here: https://github.com/asutton/origin, but I'm still working on a usable release and appropriate documentation. And it only compiles against GCC from trunk. I'm hoping for adequate documentation by next week.
'Concepts lite' were already accepted for C++17
No, it isn't. It's a separate TS.
will any concepts come predefined?
Not by the Concepts TS, which is limited to the language feature. The current Ranges TS working draft does define a number of concepts.
Running a lambda on scope exit seems like such a basic thing, I would expect it to be standardized. Things like unique_ptr are better, when they apply, but I find there is an endless supply of "one-off" destructors are needed, especially when leveraging C-style libraries. Does anyone know if this is coming?
n4189 is a proposal to add make_scope_exit wrappers, and other similar resource handlers, to the language. It is based off of the relatively famous scope_guard talk.
The most recent "current paper status" from LWG is in 2013, prior to the above date.
The contents of C++1z (hopefully C++17) are yet to be determined.
C++1z status for clang does not mention it. C++1z TS for clang does not mention it.
The paper itself contains an example implementation. I do not know what licensing terms it is under.
It would appear that the current version of the scope exit paper, P0052, will be going into the Library Fundamentals v3, for likely adoption in the Post-C++17 standard.
In short, not gonna happen for C++17. Sorry.
Running a lambda on scope exit seems like such a basic thing, I would expect it to be standardized. Things like unique_ptr are better, when they apply, but I find there is an endless supply of "one-off" destructors are needed, especially when leveraging C-style libraries. Does anyone know if this is coming?
n4189 is a proposal to add make_scope_exit wrappers, and other similar resource handlers, to the language. It is based off of the relatively famous scope_guard talk.
The most recent "current paper status" from LWG is in 2013, prior to the above date.
The contents of C++1z (hopefully C++17) are yet to be determined.
C++1z status for clang does not mention it. C++1z TS for clang does not mention it.
The paper itself contains an example implementation. I do not know what licensing terms it is under.
It would appear that the current version of the scope exit paper, P0052, will be going into the Library Fundamentals v3, for likely adoption in the Post-C++17 standard.
In short, not gonna happen for C++17. Sorry.
I've noticed that on a lot of the classic C++ reference sources that HAVE been updated for C++11, such as cplusplus.com and the Josuttis Standard Library Reference book, don't seem to cover / have any documentation at all on the C++11 concurrency standard library features, such as std::thread, std::atomic, and std::async.
Are these concurrency features somehow "less standard" than the rest of the standard library? Or is the documentation just lacking for some other reason?
All of the libraries you've referenced are indeed a part of the C++11 standard. In fact, a lot of the language rules were reworked to describe how operations work in a multithreaded environment (previously, the spec didn't specify any semantics for how threads would work).
I can't say why the documentation is lacking on those sites, since I don't know who runs them, but threads, atomics, etc. are definitely a part of C++11.
On a related note, I would strongly suggest not using cplusplus.com as a reference. It's known to have had some inaccuracies in the past, and other sites (namely, cppreference.com) are a lot more complete and accurate.
Hope this helps!