4 ms·

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

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>

pjmlp 1y ago
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.
- m-schuetz 1y ago
  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.
  - pjmlp 1y ago
    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.
account42 1y ago
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.

pjmlp 1y ago

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.

m-schuetz 1y ago
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.
- pjmlp 1y ago
  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.

account42 1y ago

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.