5 ms·

This reasoning has always rung mostly hollow for compiler features (#embed, typeof) rather than true language features (VLAs, closures). Modern toolchains must

This reasoning has always rung mostly hollow for compiler features (#embed, typeof) rather than true language features (VLAs, closures). Modern toolchains must exist for marginal systems. It's understandable to want to write code for a machine from 1975, or a bespoke MCU, on a modern Thinkpad. It is not necessary to support a modern compiler running on the machine from 1975 / bespoke MCU. You might as well argue against readable diagnostic messages because some system out there might not be able to print them!

tialaramex 4y ago
I could also see this, though perhaps it's a step too far for C, applying to Unicode encoding of source files. The 1970s mainframe this program will run on has no idea that Unicode exists. Fine. But, the compiler I'm using, which must have been written in the future after this was standardised, definitely does know that Unicode exists. So let's just agree that the program's source code is always UTF-8 and have done with it. Jason Turner has a talk where the big reveal is, the reason the slides were all retro-looking was that they were rendered in real time on a Commodore 64. The program to do that was written in modern C++ and obviously can't be compiled on a Commodore 64 but it doesn't need to be, the C64 just needs to run the program.
- morelisp 4y ago
  This seems a step too far for me. Compatibility with existing source files which may not be trivial to migrate does also matter. (Well, except for `auto`, C23 was right to fuck with that.) At the very least you'll need flags that mean "do whatever you did before".
  - tialaramex 4y ago
    Sure, I don't seriously expect C to embrace that, even though I think it'd be worth the effort I'm sure plenty of their users don't. For auto I think the argument is that if you poke around in real software the storage specifier was basically never used because it's redundant. That's the rationale WG21 had to abolish its earlier meaning in C++ before adding type deducing auto. As I read it, N2368 (which I think is what they took?) gives C something more similar to the type inference found in many languages today (which gives you a diagnostic if it can't infer a unique type from available information) whereas C++ got deduction which will choose a type when ambiguous, increasing the chance that a maintenance programmer misunderstands the type of the auto variable. However it got inference from return, which I think is a misfeature (although I think I can see why they took it, to make generics nicer). With inference from return, to figure out what foo(bar)'s type is, I need to read the implementation of foo because I have to find out what the return statements look like. It's more common today to decide we should know from the function's signature. This is somewhat mitigated by the fact that N2368 says auto won't work in extern context, so we can't just blithely say "This object file totally has a function which returns something and you should figure out what type that is" because that's clearly nonsense. You will have the source code with the return statements in it.
    - uecker 4y ago
      We took N3007 which does not have inference on return etc. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm
      - tialaramex 4y ago
        Ah, great. I don't write very much C any more, but the auto described in N3007 (well, the skim of N3007 I just did) feels very much like what I'd want from this feature in C and perhaps more importantly, what I'd assume auto does if I see it in a snippet of somebody else's code I'm trying to understand.
        hi_herbert 4y ago
        Or how to make everyone life worse for the few weirdos that don't use a LSP/IDE. The type of auto on the return of a function can and is automatically shown e.g. https://resources.jetbrains.com/help/img/rider/2022.1/inlay_hints_dependent.png https://resources.jetbrains.com/help/img/rider/2022.1/inlay_... With this kind of non-consideration of the developer comfort, it is clear C is an obscolete language.
    - saagarjha 4y ago
      C++ got auto because C++11 introduced types that could not be named, and this had to be inferred using auto.

tialaramex 4y ago

I could also see this, though perhaps it's a step too far for C, applying to Unicode encoding of source files. The 1970s mainframe this program will run on has no idea that Unicode exists. Fine. But, the compiler I'm using, which must have been written in the future after this was standardised, definitely does know that Unicode exists. So let's just agree that the program's source code is always UTF-8 and have done with it. Jason Turner has a talk where the big reveal is, the reason the slides were all retro-looking was that they were rendered in real time on a Commodore 64. The program to do that was written in modern C++ and obviously can't be compiled on a Commodore 64 but it doesn't need to be, the C64 just needs to run the program.

morelisp 4y ago
This seems a step too far for me. Compatibility with existing source files which may not be trivial to migrate does also matter. (Well, except for `auto`, C23 was right to fuck with that.) At the very least you'll need flags that mean "do whatever you did before".
- tialaramex 4y ago
  Sure, I don't seriously expect C to embrace that, even though I think it'd be worth the effort I'm sure plenty of their users don't. For auto I think the argument is that if you poke around in real software the storage specifier was basically never used because it's redundant. That's the rationale WG21 had to abolish its earlier meaning in C++ before adding type deducing auto. As I read it, N2368 (which I think is what they took?) gives C something more similar to the type inference found in many languages today (which gives you a diagnostic if it can't infer a unique type from available information) whereas C++ got deduction which will choose a type when ambiguous, increasing the chance that a maintenance programmer misunderstands the type of the auto variable. However it got inference from return, which I think is a misfeature (although I think I can see why they took it, to make generics nicer). With inference from return, to figure out what foo(bar)'s type is, I need to read the implementation of foo because I have to find out what the return statements look like. It's more common today to decide we should know from the function's signature. This is somewhat mitigated by the fact that N2368 says auto won't work in extern context, so we can't just blithely say "This object file totally has a function which returns something and you should figure out what type that is" because that's clearly nonsense. You will have the source code with the return statements in it.
  - uecker 4y ago
    We took N3007 which does not have inference on return etc. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm
    - tialaramex 4y ago
      Ah, great. I don't write very much C any more, but the auto described in N3007 (well, the skim of N3007 I just did) feels very much like what I'd want from this feature in C and perhaps more importantly, what I'd assume auto does if I see it in a snippet of somebody else's code I'm trying to understand.
      - hi_herbert 4y ago
        Or how to make everyone life worse for the few weirdos that don't use a LSP/IDE. The type of auto on the return of a function can and is automatically shown e.g. https://resources.jetbrains.com/help/img/rider/2022.1/inlay_hints_dependent.png https://resources.jetbrains.com/help/img/rider/2022.1/inlay_... With this kind of non-consideration of the developer comfort, it is clear C is an obscolete language.
  - saagarjha 4y ago
    C++ got auto because C++11 introduced types that could not be named, and this had to be inferred using auto.