Hacker News Reader

Comment by account42 | Hacker News Reader

It is a bit sad to see this for newer features. Maybe the committee should re-evaluate how quickly new designs are pushed into the standard and allow for a bit more time for evaluation. Moving fast makes sense when it's ok to break thinks, not so much when you need to support the result forever.

View on HN

Although C++ is one of my favourite languages, I feel the current WG21 process is broken, it is one of the few language evolution processes where proposals are allowed to be voted in without any kind of preview implementation for community feedback, or even to actually validate the idea.

I have to acknowledge that none of the other ISO languages, including C, are this radical.

That is how we are getting so much warts of lately.

Unfortunelly there doesn't seem to exist any willingness to change this, until it will be too late to matter.

that's not true, implementations are more often required than not

std::future was caught in coroutine/network/concurrency/parallelism master plan that has been redesigned way too many times. Sender/Receivers is the the current direction, and while I don't dislike it, we are still far for a final design to cover all use cases (we still don't have a sender/receiver network library proposal I think).

Whatever we end up with, std::future just wasn't a good base for an high performance async story. Still just adding a readiness callback to std::future would make it infinitely more useful even if suboptimal. At least it would be usable where performance is not a concern.

There is such a proposal

A recent one? Do you remember the doc number?

edit: if you mean the concurrency TS, I think that's dead right?

http://wg21.link/P2762

C++ really needs a fast-deprecate and kick out strategy for features that have proven to be poor - whether by bad design or bad implementation. And compilers should auto warn about such features.

On the contrary, I think they should move faster and provide more convenience functions that are "good enough" for 90% of use cases. For power users, there will always be a library that addresses domain-specific issues better than the standard could ever hope to.

Instead, the comitee attempts to work towards perfect solutions that don't exist, and ends up releasing overengineered stuff that is neither the most convenient, performant, nor efficient solution. Like <random>

And who gets to implement those ideas faster, many of which were never implemented before being added into the standard in first place?

The surviving three compilers are already lagging as it is, none of them is fully 100% C++20 compliant, C++23 might only become 100% on two of them, lets see how C++26 compliance turns out to be, meanwhile C++17 parallel algorithms are only fully available in one of them, while the two other ones require TBB and libstdc++ to actually make use of them.

I'm obviously not talking about modules-level features that may never get to see the light of day.

A random(min, max) function isn't rocket science and already a major inprovement over the three-liner that is currently necessary. The major compiler devs won't take long to implement these cases, just as it did not take them long to implement simple yet useful functionality in previous versions of the standard. And the standard library is full with these cases of missing convenience functions over deliberately over-engineered functions.

Modules have already seen the light of day in VC++ and clang.

Anyone using a recent version of Office, is using code that was written with C++20 modules.

It is relatively easy to see how far behind compiler developers are regarding even basic features.

Note that two of the three major surviving compilers are open source projects, and in all three major compilers, the big names have ramped down their contributions, as they rather invest into their own languages, seeing the current versions as good enough for existing codebases.

Well designed functions that deliberately target only 90% of use cases are fine.

Badly designed library types that end up being effectively deprecated but you still need to deal with for decades because they end up in all kinds of interfaces are not.

I wouldn't mind if they actually _fix_ features afterward, even if it means breaking change.

Users would mind though. Strong backwards compatibility is a very useful feature even if it does mean that you need to be careful about new additions.

Reply on news.ycombinator.com