Were they? They're great and all but from a practical standpoint I'm most excited about networking being baked in. I do almost nothing nowadays that doesn't require some form of networking. Now I can do it without bringing in any extra dependencies beyond the STL? And it's portable? Yes please!
I'm not a huge C++ developer. Maybe if I was other things would be more important to me. But adding in networking makes me want to use the language again.
Instead we'll get something carved out of ASIO, which is a complete mess full of gross unintuitive APIs and callbacks.
For many applications where C++ is used, promises and futures introduce unnecessary overhead. On the other hand an ASIO-like interface works just fine.
Additionally, ASIO, and by extension the network proposal, have transparent opt-in support for futures via a special callback type.
> opt-in support for futures via a special callback type.
Which is ugly. The coroutines opt-in as well. Coroutines actually have the potential to be faster than callbacks.
Though you have a great point. Really miss using C++ and while it still has tons of awesome ideas / stuff parts of it are just really far behind many other languages. I'd love to see modules come in and someone create a good package manager that uses them.
Coroutines would also have been useful in many circumstances.
Also C++14 was a step forward, generic lambdas are a step forward (boost::hana is based on this, and brings though compile times down), I expect similar language features in C++17, that ease the programming and will bring new innovations to C++.
Your boost argument is only valid for library features. Modules or concepts can never be a part of boost in the way they are in the TS.
No new standard then. The C++ compilers, standard libraries and the ecosystem have barely caught up with C++11, and C++ 17 was now on the horizon. If it doesn't bring much benefit, then it really cannot justify the compatibility nightmares. I for one will skip it.
> Your boost argument is only valid for library features.
That is exactly the point. Library features are not exciting as they can be implemented just fine and better by third parties. Therefore a C++ standard with only library features are hardly useful at all.
That's not really true. Both GCC and Clang have reached C++11 and C++14 feature-complete status very quickly.
As an aside, anyone can join the committee if they really wanted to see a particular language feature see the light of day in a certain way. It's not as hard as you might think. All it takes is a bit of hard work on any sufficiently motivated individual's part.
There's a great discussion of the process here: https://www.youtube.com/watch?v=PqU_ot4BlNQ
Eric Nieblers Range-v3 library is available:
https://github.com/ericniebler/range-v3/
Its not going to be (much) better in the standard...
Except that it would use real concepts then...
> Check out the (woefully incomplete) documentation here.
and
> No promise is made about support or long-term stability. This code will evolve without regard to backwards compatibility.
That's not to say I blame him, but you really shouldn't be recommending range-v3 for general use.
Concepts, modules and coroutines were perhaps the three most anticipated features, and they failed to deliver all three. No STL2 either. Woeful. The field is now wide open for the next 5 years for Rust to come along and eat C++s lunch.
The whole TS/std::experimental idea is just a folly. As a C++ programmer I just don't care if a library is available via a TS vs Boost. There's literally zero advantage to a TS. None. I'd rather stick with Boost, because then at least I only have one implementation to test against, instead of three, each with their own bugs, omissions and performance characteristics.
I've even taken to using boost::container::string where I can, instead of std::string, because the libc++ and stdlibc++ implementations have different performance characteristics.