4 ms·

Don't know, most likely reason is probably that the C standard was always an afterthought and 'reactive' in the C world (e.g. the language already existed for n

Don't know, most likely reason is probably that the C standard was always an afterthought and 'reactive' in the C world (e.g. the language already existed for nearly two decades before the first standard was released). TBH I think the general idea of "let's only standardise what has already been implemented in real world extensions and proven its worth" isn't too bad, especially when looking at the mess that the C++ standard committee made of C++ in the last decade. But even with this pragmatic approach I imagine it's a highly political balancing act to get multiple powerful compiler vendors to actually agree on the same thing. See for instance the C23 auto proposal which contains a special exception for Clang's behaviour which clashes with GCC's behaviour: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm

buserror 3y ago
Problem is, that approach forces the committee to roll in stuff from the C++ spec -- stuff that would have been shot in flame if you had hinted about that sort of things as a proposal C extension.. For example the [[keywords]] that had was rolled in because it was already out there -- imagine proposing that out of the blue and see a people self-propel into orbit... On other hand the Case A ... B: syntax that has been out there for 30+ years, well there's a proposal for it but it won't be THAT because well it hasn't been invented here really, we'll make up a different syntax for it instead...
- sigsev_251 3y ago
  Well there is a reason for that. The A ... B syntax requires that you use spaces between A, the three dots and B, else it will be lexed as a single number. C is supposed to ignore whitespace, it wouldn't make sense to add a feature that requires whitespace.
  - buserror 3y ago
    It doesn't requires a space, you could modify the lexer to recognize '..' as a prefix and solve that problem, it's just a choice they made to refuse that it could be implemented by just having one character forward looking lexer. It is not because it is implemented like that in gcc (requiring a space, possibly so they didnt have to modify the lexer) that it ought to be specced like that.
    - teo_zero 3y ago
      All C lexers are greedy, i.e. they extend the current token as far as they can. So "0..9" is split as a token "0." (numeric literal) followed by token "." (operator) followed by token "9" (numeric literal). To do what you suggest, the lexers would need a major redesign, not just a small change.
- avar 3y ago
  C still supports EBCDIC, and other potential non-ASCII character sets one might invent in the future. It promises e.g. that 0..9 is contiguous, but e.g. "case 'A' ... 'Z'" would behave differently.
  - buserror 3y ago
    That has clearly prevented dozens of other languages to support that feature... because no parser would be able to tell you that range isn't valid at compile time?
    - Someone 3y ago
      In EBCDIC, ‘Z’ > ‘A’, so the range 'A' ... 'Z' is valid, but may not do what the programmer intended. Most other languages never supported EBCDIC or dropped it long ago. (Also: 'A' ... 'Z' may not do what the programmer intended in most other languages, too. Even ignoring Unicode, quite a few encodings have accented letters that are outside of that range)
- uecker 3y ago
  One problem is that the important compilers are today mostly controlled by C++ people, and smaller C compilers and C users are underrepresented. Every change in C that is different to what C++ has already is an uphill battle.
mananaysiempre 3y ago
> the C23 auto proposal which contains a special exception for Clang's behaviour which clashes with GCC's behaviour Can you explain what that is? There’s supreme awkwardness around allowing `auto int i;` at block scope to work as before (with `auto` being ignored), but I’ve stared at that proposal a fair bit and haven’t noticed such an exception there.
- flohofwoe 3y ago
  The details are buried in the proposal and make for an interesting read, but the gist is that Clang's C frontend has a "C++ style" auto keyword where a pointer can be declared both with "auto" and "auto*" (and this was already baked into the existing __auto_type extension before C23 came along). For instance this is valid Clang C23 code (and entirely C23 standard-compliant): int i = 0; auto p0 = &i; auto* p1 = &i; ...both p0 and p1 have the same type of int*. In GCC this code doesn't compile because GCC already had a simpler "C style" __auto_type extension which doesn't allow the form "auto*", but this behaviour is also entirely valid C23 ¯\_(ツ)_/¯. (personally I prefer GCC's version as it makes more sense for C) This will cause some head-scratching when code that builds on Clang doesn't build on GCC, especially since Clang usually tries to emulate GCC behaviour. But OTH I think/hope that C's auto will only be used when absolutely necessary in "type-generic" macros, and no "almost always auto" nonsense which was fashionable in the C++ world for a while.

buserror 3y ago

Problem is, that approach forces the committee to roll in stuff from the C++ spec -- stuff that would have been shot in flame if you had hinted about that sort of things as a proposal C extension.. For example the [[keywords]] that had was rolled in because it was already out there -- imagine proposing that out of the blue and see a people self-propel into orbit... On other hand the Case A ... B: syntax that has been out there for 30+ years, well there's a proposal for it but it won't be THAT because well it hasn't been invented here really, we'll make up a different syntax for it instead...

sigsev_251 3y ago
Well there is a reason for that. The A ... B syntax requires that you use spaces between A, the three dots and B, else it will be lexed as a single number. C is supposed to ignore whitespace, it wouldn't make sense to add a feature that requires whitespace.
- buserror 3y ago
  It doesn't requires a space, you could modify the lexer to recognize '..' as a prefix and solve that problem, it's just a choice they made to refuse that it could be implemented by just having one character forward looking lexer. It is not because it is implemented like that in gcc (requiring a space, possibly so they didnt have to modify the lexer) that it ought to be specced like that.
  - teo_zero 3y ago
    All C lexers are greedy, i.e. they extend the current token as far as they can. So "0..9" is split as a token "0." (numeric literal) followed by token "." (operator) followed by token "9" (numeric literal). To do what you suggest, the lexers would need a major redesign, not just a small change.
avar 3y ago
C still supports EBCDIC, and other potential non-ASCII character sets one might invent in the future. It promises e.g. that 0..9 is contiguous, but e.g. "case 'A' ... 'Z'" would behave differently.
- buserror 3y ago
  That has clearly prevented dozens of other languages to support that feature... because no parser would be able to tell you that range isn't valid at compile time?
  - Someone 3y ago
    In EBCDIC, ‘Z’ > ‘A’, so the range 'A' ... 'Z' is valid, but may not do what the programmer intended. Most other languages never supported EBCDIC or dropped it long ago. (Also: 'A' ... 'Z' may not do what the programmer intended in most other languages, too. Even ignoring Unicode, quite a few encodings have accented letters that are outside of that range)
uecker 3y ago
One problem is that the important compilers are today mostly controlled by C++ people, and smaller C compilers and C users are underrepresented. Every change in C that is different to what C++ has already is an uphill battle.

mananaysiempre 3y ago

> the C23 auto proposal which contains a special exception for Clang's behaviour which clashes with GCC's behaviour Can you explain what that is? There’s supreme awkwardness around allowing `auto int i;` at block scope to work as before (with `auto` being ignored), but I’ve stared at that proposal a fair bit and haven’t noticed such an exception there.

flohofwoe 3y ago
The details are buried in the proposal and make for an interesting read, but the gist is that Clang's C frontend has a "C++ style" auto keyword where a pointer can be declared both with "auto" and "auto*" (and this was already baked into the existing __auto_type extension before C23 came along). For instance this is valid Clang C23 code (and entirely C23 standard-compliant): int i = 0; auto p0 = &i; auto* p1 = &i; ...both p0 and p1 have the same type of int*. In GCC this code doesn't compile because GCC already had a simpler "C style" __auto_type extension which doesn't allow the form "auto*", but this behaviour is also entirely valid C23 ¯\_(ツ)_/¯. (personally I prefer GCC's version as it makes more sense for C) This will cause some head-scratching when code that builds on Clang doesn't build on GCC, especially since Clang usually tries to emulate GCC behaviour. But OTH I think/hope that C's auto will only be used when absolutely necessary in "type-generic" macros, and no "almost always auto" nonsense which was fashionable in the C++ world for a while.