Hacker News Reader

Comment by buserror | Hacker News Reader

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...

View on HN

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.

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.

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.

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.

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.

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?

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)

Reply on news.ycombinator.com