I have gripes with many parts of the process, predominantly the committee.
> Keep in mind that the ISO committee does not employ engineers and for international treaty reasons, it reasonably cannot.
Engineers not being employed by the committee doesn't meani can't hold them to a standard. The standards committee have shown that they're more interested in freesing popular libraries and putting them in the standard library. It's clear that major changes are preferred as library changes not language changes (ranges should be a language feature, as should span and optional).
> who should be doing this work?
I'm not sure what you're getting at here. The standards committee should have used some time between 2004 (when this was proposed first) and 2019 to get this done. The compiler vendors, 4 years later , should have made this usable. The build systems are at the mercy of the compiler vendors, but cmake has had 3-4? years to get this in.
> Are you talking to them about your expectations? Are you providing actual support to implementations that are public goods (i.e., open source compilers)?
It's not fair for you to suggest that it's my fault this is a mess, 15 years on.
To answer your question, I've tried multiple times over the last 3 years, hit show stopping bugs and issues, and have found them already reported in clang's issue tracker or the VS feedback forums. I've spoken with developers here and on Reddit about issues with MSVC, and cmake.
> It's not fair for you to suggest that it's my fault this is a mess, 15 years on.
All I did was ask specific questions. Specifically, who are you griping about?
It's also not fair to expect ISO, a documentation and consensus building body, to act like an engineering org under contract to us. That's not what it does, and it really couldn't do that if it wanted to.
Reporting, clarifying, and otherwise contributing issues is helpful of course. But bottom line is that someone needs to implement fixes.
I just want to make sure we're all aren't just sitting in a big room yelling about why someone isn't just fixing to things for us. Most of the time it seems like we're not far off from that.
We should be holding our vendors more accountable of course. But also our leadership (like CTO offices) that seem fine using all the open source tech for free without contributing back in any form.
But ISO? I think it is being too complicated for volunteer compiler contributions to keep up with, but I don't think putting more language features in C++ is going to help that at all.
Maybe we call C++ dysfunctional and move on to something else, but I don't see how the same problems don't just show up there in another ten years. It's hard to get around lack of funding. Syntax isn't going to fix funding issues. Consolidation could, but we seem to be going the other direction, at least in the short term.
> s also not fair to expect ISO, a documentation and consensus building body, to act like an engineering org under contract to us. That's not what it does, and it really couldn't do that if it wanted to.
This is a bad faith strawman argument. You're the one who said they're not employees. Again, they can be held accountable for their decisions whether they're employees or not.
> But also our leadership (like CTO offices) that seem fine using all the open source tech for free without contributing back in any form.
Speak for yourself here. Many people (myself included) work at organisations that do contribute back either financially, or by reporting issues and submitting fixes (both of which I've done to our OSS dependencies in the last month). It's not fair of you in one breath to say "I'm just asking questions", "what exactly are _you_ doing to fix this", and immediately follow it with "nobody is contributing anything back". And if your response here is that you weren't talking about me specifically, then you need to decouple your interrogation from your soapbox.
> But ISO? I think it is being too complicated for volunteer compiler contributions to keep up with,
The volunteer compilers like MSVC (which is proprietary), gcc (which based on last time I looked is primarily developed by employees from red hat and IBM), or Clang which has been massively contributed to by apple and Google up until very recently?
> s hard to get around lack of funding. Syntax isn't going to fix funding issues.
I'm not sure what you're getting at here, at all.
> Consolidation could, but we seem to be going the other direction, at least in the short term.
Agreed here, unfortunately. We've had a decade plus of consolidation, and what we've ended up with is a camel (IMO)
It's an opinion I feel strongly about, though. Honestly, I think c++'s reliance on library features to patch over deficiencies in the language is a cop out. We knew about the unique pointer abi performance issue a decade ago, and decided that string view should be implemented the same way.
Ranges are "the kitchen sink", and cause significant compile time issues whether you want to use them or not.
Spending time on libraries like fmt (which is an excellent library) is paying lip service to progress by locking in a 5 year old library (at this point).
> The spirit of C/C++ is to put just enough in the language itself to allow programmers to implement such things in them
To use your own words against you, that's an opinion. Mine is the spirit of C++ (which were talking about here, not C) is to not rock the boat too hard or everyone will have an opinion.
> Keep in mind that the ISO committee does not employ engineers and for international treaty reasons, it reasonably cannot.
Engineers not being employed by the committee doesn't meani can't hold them to a standard. The standards committee have shown that they're more interested in freesing popular libraries and putting them in the standard library. It's clear that major changes are preferred as library changes not language changes (ranges should be a language feature, as should span and optional).
> who should be doing this work?
I'm not sure what you're getting at here. The standards committee should have used some time between 2004 (when this was proposed first) and 2019 to get this done. The compiler vendors, 4 years later , should have made this usable. The build systems are at the mercy of the compiler vendors, but cmake has had 3-4? years to get this in.
> Are you talking to them about your expectations? Are you providing actual support to implementations that are public goods (i.e., open source compilers)?
It's not fair for you to suggest that it's my fault this is a mess, 15 years on.
To answer your question, I've tried multiple times over the last 3 years, hit show stopping bugs and issues, and have found them already reported in clang's issue tracker or the VS feedback forums. I've spoken with developers here and on Reddit about issues with MSVC, and cmake.