7 ms·

> Some compiler needs to implement -Wunderbar Hidden gem! On a more serious note, the author of this little proposal (officializing "_" as a no name placehold

> Some compiler needs to implement -Wunderbar Hidden gem! On a more serious note, the author of this little proposal (officializing "_" as a no name placeholder) had to perform a thorough research to show that this change would not break existing code. This kind of attention is necessary for a language with broad scope and a long successful history such as C++, and would be for every other language with such characteristics. While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old.

lifthrasiir 3y ago
> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. This is true, but C++ hasn't learned enough from other languages' experiences either. Let's assume that `_` couldn't not be introduced without breaking changes. Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). C++ is still struggling with a false premise of stable ABI (see [1] for a good argument against it). [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-...
- jmgao 3y ago
  > Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). You can't really do this in a language where the way you use libraries is by textual inclusion of headers which can include arbitrary code (no one uses modules).
  - tialaramex 3y ago
    The proposal (Epochs) to do this in C++ even says it needs modules. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... It would have been extremely difficult to do this for say C++ 20 even if the other work was abandoned (which IMO would have been sensible) and I feel confident it is now impossible.
  - lifthrasiir 3y ago
    That's a bad excuse. In fact I think editions are possible without modules at all, if you are really willing to fix this issue. Tying epochs to modules suggests that they don't think this is a huge issue to start with. One possible design is to assign editions to all preprocessed tokens. This implies the edition definition should be some sort of pragma (say, `#pragma STDCXX EDITION 2023`) and preprocessors should add pragmas themselves if tokens with a different edition are transcluded into other tokens. Implementations with integrated preprocessor and parser may also use a simpler internal representation to convey editions as well. Now `_` would be a normal identifier in past editions and a placeholder in a new edition, however they are passed through macros. For example: #pragma STDCXX EDITION 2023 // Hereafter `_` is parsed as `_2023` internally #define GUARD() auto _ = make_guard() #pragma STDCXX EDITION 2020 // Hereafter `_` is parsed as `_2020` internally { GUARD(); GUARD(); // Okay, equivalent to `auto _2023 = make_guard();` foo(&_); // Up to the proposal author, but P2169 suggests that // this `_` should refer to the second `_2023` } auto _ = make_guard(); // Okay, equivalent to `auto _2020 = make_guard();` auto _ = make_guard(); // Nope, `_2020` can't be defined more than once in the same scope Of course there are more questions to answer. For example what would `#` and `##` do to editions? Should the current edition reset after `#include` finishes? (I think so.) How would we compute the edition for specific syntax from constituent tokens? (A systematic approach would be to collect a set of all editions used in syntactic tokens, and if not all editions in that set result in the same result, to issue an error.) But I still argue that this design is simple, checks all checkboxes as long as open questions are decided, and can be independently deployed. And this token-level tracking is not something alien, it's required to give more accurate diagnostics anyway---and other languages like Rust have even used it to implement things like macro hygiene.
dthul 3y ago
There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.
- eesmith 3y ago
  I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.
  - lifthrasiir 3y ago
    Note that this tool (crater) is mainly used to catch regressions, not to judge whether it's worth to intentionally break things (which is what editions are for). If many crates depend on the bug which devs want to fix crater will probably detect that and devs will consider other alternatives.
  - Entalpi 3y ago
    Pretty sure from a build system perspective its quite a flex .. to be fair.
    - eesmith 3y ago
      I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself (eg, the FORTRAN code in Sibson's 1973 "SLINK" paper), or only distributed as a zip file from the author's web site, or in the supplementary data (eg, https://scholar.google.com/scholar?q=%22source+code+in+the+supplementary%22 https://scholar.google.com/scholar?q=%22source+code+in+the+s... ) . Personally, I don't think it's true. I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.
TeMPOraL 3y ago
> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. (content warning: below are just some thoughts without any kind of final point or argument; skip if you're not interested in random musings) Makes me think of evolution, biological death, and the limits of lessons learned. C++[0] embeds decades of practical experience; many mistakes and pivots add up to how it looks today - but every change made meant complexity was growing, and today, it's hard to incorporate new experience into the language, because of all that accumulated complexity. New languages get to distill what works, and incorporate the lessons into their design directly - starting fresh, without the complexity baggage. However, some things are lost in translation - all that complexity thrown away wasn't just random noise, it was a record of mistakes and wrong turns that the new languages are now liable to repeat. What I'm thinking is: evolving a language for decades keeps all the experience, but becomes superlinearly[1] expensive and slow. Starting from scratch resets the costs, but also loses some experience in the process. Where continuous evolution of a language, in the limit, will be approaching the point where incremental upgrade takes infinite effort to pay the "complexity debt", the "one funeral at a time" evolution seems like it could reach a different limit: the point at which it each generational transition loses as much experience as the subsequent generation will add. Not sure what to make of it yet. -- [0] - I'm including here both the language proper, standard library and compilers, which all co-evolved, and all form the larger body of C++ as a real tool, and not just paper abstraction. [1] - Would say exponentially, but I'm not really sure how fast it grows - only that it grows faster than linear.
- einpoklum 3y ago
  > New languages get to distill what works, and incorporate the lessons into their design directly In principle. In practice, most new languages distill _some_ of what works and incorporate _some_ lessons. Which is ok, but the point is that when they hit those situations where things _don't_ work, they either ignore it or start becoming more complex themselves. > but becomes superlinearly[1] expensive and slow Are you talking about the language standard? The standard library API? Idiomatic use "cognitive load"? Advanced use brain load? For some of these, your statement is not true. Especially for the idiomatic use of the language: Quite a few things have gotten simpler, rather than more complex, for the lay user, with the addition of more functionality into the language.
ReleaseCandidat 3y ago
No. This is actually the biggest error C++ made. C++ should have learned from Fortran 77 -> 90 and made C++11 a new language and either let the compilers handling compatibility of C++98 and C++11 or introduce some compatibility functions like `extern C`.
- gpderetta 3y ago
  No. 99% backward source compatibility was a primary requirement for C++11. It was bad enough that the ABI was broken.
  - ReleaseCandidat 3y ago
    That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).
    - gpderetta 3y ago
      People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files. If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...
      - ReleaseCandidat 3y ago
        > People want to use new features in existing files Yes, and it would have been The Right Thing(TM) to ignore these people. > And they expect to link seamlessly the existing files against new files. As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ and there are actually other languages using even other compilers or interpreters or VMs that can use C++. And ignoring the problems when calling a C++ library compiled by another C++ compiler on Windows.

lifthrasiir 3y ago

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. This is true, but C++ hasn't learned enough from other languages' experiences either. Let's assume that `_` couldn't not be introduced without breaking changes. Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). C++ is still struggling with a false premise of stable ABI (see [1] for a good argument against it). [1] https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-help-me-god-please https://thephd.dev/binary-banshees-digital-demons-abi-c-c++-...

jmgao 3y ago
> Even in that case it would be reasonable to opt in that syntax for some blocks of code, without breaking any existing code which hasn't opted in, and this "edition" mechanism was very successful to evolve syntaxes and often semantics in recent languages (JS, Rust, ...). You can't really do this in a language where the way you use libraries is by textual inclusion of headers which can include arbitrary code (no one uses modules).
- tialaramex 3y ago
  The proposal (Epochs) to do this in C++ even says it needs modules. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... It would have been extremely difficult to do this for say C++ 20 even if the other work was abandoned (which IMO would have been sensible) and I feel confident it is now impossible.
- lifthrasiir 3y ago
  That's a bad excuse. In fact I think editions are possible without modules at all, if you are really willing to fix this issue. Tying epochs to modules suggests that they don't think this is a huge issue to start with. One possible design is to assign editions to all preprocessed tokens. This implies the edition definition should be some sort of pragma (say, `#pragma STDCXX EDITION 2023`) and preprocessors should add pragmas themselves if tokens with a different edition are transcluded into other tokens. Implementations with integrated preprocessor and parser may also use a simpler internal representation to convey editions as well. Now `_` would be a normal identifier in past editions and a placeholder in a new edition, however they are passed through macros. For example: #pragma STDCXX EDITION 2023 // Hereafter `_` is parsed as `_2023` internally #define GUARD() auto _ = make_guard() #pragma STDCXX EDITION 2020 // Hereafter `_` is parsed as `_2020` internally { GUARD(); GUARD(); // Okay, equivalent to `auto _2023 = make_guard();` foo(&_); // Up to the proposal author, but P2169 suggests that // this `_` should refer to the second `_2023` } auto _ = make_guard(); // Okay, equivalent to `auto _2020 = make_guard();` auto _ = make_guard(); // Nope, `_2020` can't be defined more than once in the same scope Of course there are more questions to answer. For example what would `#` and `##` do to editions? Should the current edition reset after `#include` finishes? (I think so.) How would we compute the edition for specific syntax from constituent tokens? (A systematic approach would be to collect a set of all editions used in syntactic tokens, and if not all editions in that set result in the same result, to issue an error.) But I still argue that this design is simple, checks all checkboxes as long as open questions are decided, and can be independently deployed. And this token-level tracking is not something alien, it's required to give more accurate diagnostics anyway---and other languages like Rust have even used it to implement things like macro hygiene.

dthul 3y ago

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.

eesmith 3y ago
I'm not sure that's the flex you think it might be. At least, I interpret it as saying there isn't much publicly available Rust code, and only a few places to find Rust code. I have a hard time even estimating how long it would take to test a change against all publicly available C++ code. FWIW, the C++ standards developers use do use code search tools to help identify possible breakage.
- lifthrasiir 3y ago
  Note that this tool (crater) is mainly used to catch regressions, not to judge whether it's worth to intentionally break things (which is what editions are for). If many crates depend on the bug which devs want to fix crater will probably detect that and devs will consider other alternatives.
- Entalpi 3y ago
  Pretty sure from a build system perspective its quite a flex .. to be fair.
  - eesmith 3y ago
    I understand the intent of the flex, but if true, it suggests there's very little public Rust outside of packages that can be downloaded from crates.io and a smallish list of alternatives. By comparison, there's so much publicly available Python code, from so many sources, that no one can honestly say they can even find it all. The same for C++. I've seen papers where the source code was included in the paper itself (eg, the FORTRAN code in Sibson's 1973 "SLINK" paper), or only distributed as a zip file from the author's web site, or in the supplementary data (eg, https://scholar.google.com/scholar?q=%22source+code+in+the+supplementary%22 https://scholar.google.com/scholar?q=%22source+code+in+the+s... ) . Personally, I don't think it's true. I suspect Rust changes - just like new proposed C++ changes - are checked against only easily and "well-known" accessible package.

TeMPOraL 3y ago

> While more modern languages benefit from the errors of the older ones, I do not think they will be exempt from this kind of responsible growth process when they will become decades old. (content warning: below are just some thoughts without any kind of final point or argument; skip if you're not interested in random musings) Makes me think of evolution, biological death, and the limits of lessons learned. C++[0] embeds decades of practical experience; many mistakes and pivots add up to how it looks today - but every change made meant complexity was growing, and today, it's hard to incorporate new experience into the language, because of all that accumulated complexity. New languages get to distill what works, and incorporate the lessons into their design directly - starting fresh, without the complexity baggage. However, some things are lost in translation - all that complexity thrown away wasn't just random noise, it was a record of mistakes and wrong turns that the new languages are now liable to repeat. What I'm thinking is: evolving a language for decades keeps all the experience, but becomes superlinearly[1] expensive and slow. Starting from scratch resets the costs, but also loses some experience in the process. Where continuous evolution of a language, in the limit, will be approaching the point where incremental upgrade takes infinite effort to pay the "complexity debt", the "one funeral at a time" evolution seems like it could reach a different limit: the point at which it each generational transition loses as much experience as the subsequent generation will add. Not sure what to make of it yet. -- [0] - I'm including here both the language proper, standard library and compilers, which all co-evolved, and all form the larger body of C++ as a real tool, and not just paper abstraction. [1] - Would say exponentially, but I'm not really sure how fast it grows - only that it grows faster than linear.

einpoklum 3y ago
> New languages get to distill what works, and incorporate the lessons into their design directly In principle. In practice, most new languages distill _some_ of what works and incorporate _some_ lessons. Which is ok, but the point is that when they hit those situations where things _don't_ work, they either ignore it or start becoming more complex themselves. > but becomes superlinearly[1] expensive and slow Are you talking about the language standard? The standard library API? Idiomatic use "cognitive load"? Advanced use brain load? For some of these, your statement is not true. Especially for the idiomatic use of the language: Quite a few things have gotten simpler, rather than more complex, for the lay user, with the addition of more functionality into the language.

ReleaseCandidat 3y ago

No. This is actually the biggest error C++ made. C++ should have learned from Fortran 77 -> 90 and made C++11 a new language and either let the compilers handling compatibility of C++98 and C++11 or introduce some compatibility functions like `extern C`.

gpderetta 3y ago
No. 99% backward source compatibility was a primary requirement for C++11. It was bad enough that the ABI was broken.
- ReleaseCandidat 3y ago
  That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).
  - gpderetta 3y ago
    People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files. If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...
    - ReleaseCandidat 3y ago
      > People want to use new features in existing files Yes, and it would have been The Right Thing(TM) to ignore these people. > And they expect to link seamlessly the existing files against new files. As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ and there are actually other languages using even other compilers or interpreters or VMs that can use C++. And ignoring the problems when calling a C++ library compiled by another C++ compiler on Windows.