Is the world coming to an end?

[KennyTM~]

On Apr 3, 11 08:30, Michel Fortin wrote:
> On 2011-04-02 19:58:25 -0400, Walter Bright <newshound2 at digitalmars.com>
> said:
>
>> On 4/2/2011 4:11 PM, Michel Fortin wrote:
>>> It's funny that D (the language) has binary notation built-in (which
>>> C doesn't
>>> have) but no octal notation anymore (which C has).
>>
>> The problem with the octal literals is, as has been often complained
>> about, people getting surprised by it. I've never heard of anyone
>> being surprised by the binary or hex literals.
>
> Indeed. Isn't that a good argument for implementing octal literals the
> same way as binary and hex literals?
>
>
>>> You now have to resort to a
>>> library template for that,
>>
>> I think it's a feature, not a "resort", that library templates can do
>> this well. I think it's far better than C++0x's user defined literals,
>> for example.
>
> I disagree that it's better. With C++ user defined literals the user
> doesn't have to find by himself whether the number fits within the range
> of a regular integer literal and if not fall back to using a string as
> the template argument instead.
>

This is a problem but as I'd test it's a non-issue. Running a Google 
code search on   [^.'"-]\b0[0-7]{7,}[ulUL]*\b -0{8,}   shows only two 
instances of real (i.e. not used for testing the format function) usage 
of long (> 7 digits) octal literals in the first few pages:

     037777600000l  in Android's OpenSSL (this is 0xffff_0000L)
     077777777777L  in Apache's ASF (this is 0x1_ffff_ffffL)

Both of them fit inside 2^^63 as decimal digits for octal!(), and both 
of them could better be represented as hex if ported.

> I don't think it's much worse, but I fail to see how it could be better.
>

Avoiding needing to create another kind of literal?

>
>>> and it doesn't work for big numbers: try
>>> assert(octal!1777777777777777777777 == 0xFFFF_FFFF_FFFF_FFFF). Not
>>> that I expect
>>> anyone to want to write big 64-bit numbers in octal, but it makes the
>>> new
>>> "official" octal notation more like a hack.
>>
>> If you use octal!"1777777777777777777777" it will work correctly.
>> You're right in that the decimal literal being "converted" to octal is
>> a bit of a hack.
>>
>> The octal!1777777777777777777777 will fail at compile time with an
>> integer overflow, it never gets to the runtime assert.
>
> Which makes me wonder, what does the compiler suggests in the error
> message when it encounters 01777777777777777777777 ? I suspect it
> doesn't add the necessary quotes, does it?
>

There's no quotes, and there should be, but the extra cost for this 
branch may not worth it (the lower limit of quotes depends on whether it 
is a long/unsigned literal).

> The new syntax is certainly usable, it's just inelegant and hackish. Its
> your language, it's your choice, and I'll admit it won't affect me much.
>