bearophile wrote:
Walter Bright:
Not a significant issue, as the code to lex it is done, works, and is
readily available.
It's not an issue for the compiler, but a modern programming language has to be
designed for programmers, to be as little bug-prone as possible. Literals as .5
and 5. are not correct in my natural language, they look ugly, and they are a
bit dangerous. That's why I think it's better to disallow them.
Translating C code to D.<
The main problem is turning a literal like 0555 into a syntax error, but
failing silently or giving a different answer.
Now in Python 3+ literals like 0720 are disallowed, you have to use 0o720
instead. I was one of the people that have suggested and voted for this change.
It's one of the few changes in Python that come from a suggestion of mine.
Regarding Python 3, it contains a single built-in module that's named 2to3,
it's not too much long and it's quite useful:
http://docs.python.org/library/2to3.html
I think that writing a similar standard and built-in Python module to translate
C/H code to D can be positive. Then all D distributions can contain it. Among
the things it does it to reformat code and convert C octals to D octals :-)
Bye,
bearophile
Just make a CTFE function for converting an octal string to an int.
T octalLiteral(T=int)(string s)
{
T r=0;
foreach(c; s) {
assert(c>='0' && c<='7', "Invalid character in octal literal");
r *= 8;
r += (c-'0');
}
return r;
}
static assert(octalLiteral("012")==012);
static assert(octalLiteral("0716")==0716);
static assert(octalLiteral!(long)("071625636464")==071625636464L);
Why do we need language support for something which is so obscure and
can be so trivially implemented in a library?
(Note that it's only possible because of CTFE).
