Leandro Lucarella wrote:
That's not a good enough reason. Having *one* front-end
(lexer/parser/semantic analizer) is not good enough. D was supposed to
make this easy to encourage different implementations. If the D specs are
twisted and making a new lexer is... confusing, I think that's a failure.
It's 8 lines of code in the lexer to distinguish an octal literal from a
non-octal one. I don't see a pressing case for disastrous complexity.
Here they are:
case '0': case '1': case '2': case '3':
case '4': case '5': case '6': case '7':
state = STATE_octal;
break;
case '_':
state = STATE_octal;
p++;
continue;
D integer literals are identical to C ones, with the addition of _ and
the elidation of trailing l. It's hard for me to see how this, which has
been around 30 years in practice and 20 years as a standard, is an
understandability problem in practice or specification.
