On Thursday, 7 April 2022 at 16:38:58 UTC, Adam Ruppe wrote:

You certainly don't want to dispute that

01777777777777777777777

is actually an octal literal whose value fits in a ulong?

This concept is dubious and that is what bothers me.

Made to save two keystrokes after having typed six additional ones compared to C/C++?

The method does not work for most of the possible octal literals whose values fit in a ulong. I would call it an inconvenience method.

On Thursday, 7 April 2022 at 17:28:32 UTC, Steven Schveighoffer wrote:

Just works.

On 4/7/22 3:18 PM, kdevel wrote:

but that's not what you gave to the compiler. for octal!1777777777777777777777, the number part of that expression isn't a valid literal that fits in a ulong.

It works for all numbers below 288,230,376,151,711,744 (i.e. up to 58 bits).

So, yeah, not all of them. But many of them.

But I kind of agree with you that the integer one is full of problems.

Another problem I just realized:

    auto x1 = octal!17777777777;
    auto x2 = octal!"17777777777";
    pragma(msg, typeof(x1)); // long
    pragma(msg, typeof(x2)); // int

Why? because octal(T) takes the type of T

And there's no way to fix it. Because you'd want octal!1L to be long, so you can't just look at the value.

We might want to just undocument the integer version.

-Steve

On Thursday, 7 April 2022 at 19:59:24 UTC, Steven Schveighoffer wrote:

    auto x1 = octal!17777777777;
    auto x2 = octal!"17777777777";
    pragma(msg, typeof(x1)); // long
    pragma(msg, typeof(x2)); // int

I dont see any real problem with x1 type because you can request to have it as int without cast

int x1 = octal!17777777777;

On Thursday, 7 April 2022 at 19:59:24 UTC, Steven Schveighoffer wrote:
[...]

For the record: 1 - 2^54 / 2^64 = .9843. I.e. for 98.4 % of all possible values fitting in a ulong template octal (alias decimalInteger) does not work.

I strongly recommend deprecation and removal. Imagine what happens if someone forgets to type the quotation marks and gets a type which is wider than expected. The abolishment of the leading-zero octals shall not introduce another error category.

On 4/7/22 4:52 PM, kdevel wrote:

Please tell me the percentage of octal literals written in code (including all C code) that are in that range.

Remember, these are literals, not values that are in memory.

No imagination required -- compiler error.

Who cares? It's a compiler error if it doesn't work.

-Steve

On 4/7/22 4:18 PM, user1234 wrote:

    auto x1 = octal!17777777777;
    auto x2 = octal!"17777777777";
    pragma(msg, typeof(x1)); // long
    pragma(msg, typeof(x2)); // int

int x1 = octal!17777777777;

Yes, but auto is convenient, template IFTI will not carry forward that ability to assign to an int, etc.

I'd say we just undocument (and don't deprecate) the numeric form. Anyone who uses it can continue to do so, and once the compiler stops suggesting using it, I can't see a good reason to do it.

-Steve