5 ms·

> I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. Important questi

> I'm super disappointed with modules. It's 2023, we've pushed out a new c++ standard since modules were standardised, and they're not usable. Important question: Who are you disappointed in? Keep in mind that the ISO committee does not employ engineers and for international treaty reasons, it reasonably cannot. Point being, who should be doing this work? Are you talking to them about your expectations? Are you providing actual support to implementations that are public goods (i.e., open source compilers)?

david2ndaccount 3y ago
The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice.
- deleted 3y ago
  [deleted]
- rewmie 3y ago
  > The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice. How do you expect to standardize a feature that does not exist yet but the whole community is demanding? It sounds like the C++ standardization committee designed a feature following a process where all stakeholders had a say. Is this worse than being force-fed a vendor-specific solution?
  - david2ndaccount 3y ago
    I do not expect standardization of features that do not exist.
    - rewmie 3y ago
      > I do not expect standardization of features that do not exist. But that makes absolutely no sense, doesn't it? I mean, think about it for a moment. Specifying a standard behavior is not about picking a flawed winner from a list of ad-hoc implementation or settle with the least common denominator. Specifying a standard behavior is about providing the best possible solution that meets the design requirements following the input from the whole community.
  - kazinator 3y ago
    > How do you expect to standardize a feature that does not exist yet but the whole community is demanding? Implement it in a popular compiler or library. I know we are talking about C++, but the ISO C committee, over the past several decades, has repeatedly ignored working, good features in GCC and invented crap in their place.
    - maccard 3y ago
      This is part of the modules mess in the first place. Modules were implemented in MSVC and clang, and neither agreed with the others implementation. Also if MSVC came along with an "extension" to c++, I can only imagine the uproar suggesting that this is now step 2 of EEE.
      - deleted 3y ago
        [deleted]
maccard 3y ago
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.
- Someone 3y ago
  > ranges should be a language feature, as should span and optional That’s an opinion. As you notice, “It's clear that major changes are preferred as library changes not language changes” The spirit of C/C++ is to put just enough in the language itself to allow programmers to implement such things in them.
  - maccard 3y ago
    > That’s an opinion. That's fair, actually. 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.
kazinator 3y ago
My expectation is that the ISO C and ISO C++ committees recognize that things would be best off if they dispersed.

david2ndaccount 3y ago

The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice.

deleted 3y ago
[deleted]
rewmie 3y ago
> The ISO committee should not be in the business of inventing language features out of whole cloth. That is not how “standardization” works. They should only standardize existing practice. How do you expect to standardize a feature that does not exist yet but the whole community is demanding? It sounds like the C++ standardization committee designed a feature following a process where all stakeholders had a say. Is this worse than being force-fed a vendor-specific solution?
- david2ndaccount 3y ago
  I do not expect standardization of features that do not exist.
  - rewmie 3y ago
    > I do not expect standardization of features that do not exist. But that makes absolutely no sense, doesn't it? I mean, think about it for a moment. Specifying a standard behavior is not about picking a flawed winner from a list of ad-hoc implementation or settle with the least common denominator. Specifying a standard behavior is about providing the best possible solution that meets the design requirements following the input from the whole community.
- kazinator 3y ago
  > How do you expect to standardize a feature that does not exist yet but the whole community is demanding? Implement it in a popular compiler or library. I know we are talking about C++, but the ISO C committee, over the past several decades, has repeatedly ignored working, good features in GCC and invented crap in their place.
  - maccard 3y ago
    This is part of the modules mess in the first place. Modules were implemented in MSVC and clang, and neither agreed with the others implementation. Also if MSVC came along with an "extension" to c++, I can only imagine the uproar suggesting that this is now step 2 of EEE.
    - deleted 3y ago
      [deleted]

maccard 3y ago

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.

Someone 3y ago
> ranges should be a language feature, as should span and optional That’s an opinion. As you notice, “It's clear that major changes are preferred as library changes not language changes” The spirit of C/C++ is to put just enough in the language itself to allow programmers to implement such things in them.
- maccard 3y ago
  > That’s an opinion. That's fair, actually. 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.

kazinator 3y ago

My expectation is that the ISO C and ISO C++ committees recognize that things would be best off if they dispersed.