Number literals (Was: Re: Case Range Statement ..)

[Don]

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