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.
Related
The interface for std::future::then in the paper N3784 included an overloaded version that accepted an executor (described more here in N3562) as a parameter. So if you wanted more control over which thread the callback was executed on you could do so.
But the official document that goes over all the features that are in the concurrency TS here http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.unique_future does not include that overload for .then() and doesn't mention executors at all. It says
When the object's shared state is ready, the continuation INVOKE(DECAY_COPY(std::forward<F>(func)), std::move(*this)) is called on an unspecified thread of execution with the call to DECAY_COPY() being evaluated in the thread that called then.
Why does the interface not offer precise control of how the closure is executed? How then can one exercise control over which thread runs the callback? Why the change from the proposed version?
Note I am not sure if the concurrency TS paper I linked to is the latest one, but cppreference does not mention executors anywhere either
Edit If someone has a reference or reason in some C++ standards paper that mentions the reason for not continuing with executors, that would be great!
Why the change from the proposed version?
The TSes are trial balloons for features approaching standardization but may not be in final form yet. They are a chance for the standards committee to get experience to see what does and doesn't work in the real world.
Since there is at least one newer proposal for executors, it seems the working group wasn't satisfied with executors as they were in the TS and are refining them before standardization.
How then can one exercise control over which thread runs the callback?
Right now, it seems you'd have to depend on a language or library extension or roll your own. I haven't studied the proposal enough to say how you would do it if the proposal becomes part of the standard, but it looks like then_execute, which can be a free function or a member of the executor object, would be the key.
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.
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.
There is lots of sweet stuff in TR2. Is that going to be in C++17?
I understand that TR1 was completed in 2005 and had to wait until C++11 to be standardized.
But I also understand that TR2 is already complete?
My link to C++17 doesn't mention anything about TR2, but I am hoping...
Maybe.
The point of TR (and now technical specifications) is to allow something to mature independent of the standard iteration process. They can publish a TS, see how it works, see if there are any problems in the implementation and/or use of the feature, and if everything works they can then "fold" it into the full standard.
Each TS is considered on its own merits to see if it will be folded into the next standard.
See http://isocpp.org/std/status (thanks #BenjaminLindley) for current status of the Technical Specification working groups.
Any of them, if completed well prior to 2017, could be folded into the standard. It is unlikely they all will be.
A goal is that we can get the std::experimental features to play with (and use if we are willing to accept the ground shifting under our feet) earlier, while having the features once added to std with fewer regrets and specification changes after that point. There are probably also massive organizational overhead advantages to decoupling the main line standard from each of these side projects and allowing them to evolve independently.
The purpose of a Technical Report, or Technical Specification as they are now, is to gain implementation experience and feedback from implementors and users, to better assess the suitability of features for standardization. One would need a crystal ball to know if a particular TS will be included in a future standard, and which future standard that might be.
Version 1 of the Library Fundamentals TS appears to have passed its final ballot at the November 2014 committee meeting, and version 2 is currently being drafted to incorporate feedback and new proposals. This means it is getting closer to being something which implementors and industry users are happy with, and version 1 is now an immutable specification which implementors can choose to conform to. It is still more than possible for later versions, and later standards, to change in ways which would be incompatible with version 1.
Here's a list (from your wikipedia link) of the features of TR2 - and my comments:
Threads - Included in C++11
The Asio C++ library - this is being considered for a future C++ standard
Signals/Slots - no action at this time (that I know of)
Filesystem Library - FileSystem Technical Specification
Boost Any Library - Part of the Library Fundamentals Technical Specification
Lexical Conversion Library - no action at this time (that I know of)
New String Algorithms - no action at this time (that I know of)
Toward a More Complete Taxonomy of Algebraic Properties for Numeric Libraries in TR2 - no action at this time (that I know of)
Adding heterogeneous comparison lookup to associative containers for TR2 - * Included in C++14*
Are there any features of C++0x that are known to be there for sure?
Like, maybe, threads in the standard library?
Actually none. At any point up to the publication of the standard, ISO can change it, since it's subject to the vagaries of the voting process.
In reality, any major feature that's currently in the draft will remain (although tweaking is possible). They've already stated that they'll miss their 2009 delivery and ISO is as political a beast as any country, so they'll not want to miss another one.
So while you won't see tuples or threads or other major library changes being removed, there could be minor variations, nothing that will have a major impact on delivery of the standard (and hopefully, timely implementation by the vendors).
New string literals
auto type deduction
Template typedefs
R-value references
to name a few and most of TR1.
Take a look at the C++0x Wikipedia article -- but it is best to check with your compiler vendor to know what you can use.