Regarding the proposed Binray Literals Deprecation

[Adam D Ruppe]

On Saturday, 10 September 2022 at 21:57:51 UTC, Timon Gehr wrote:
> 422 is a decimal literal. E.g., there is type deduction logic 
> in the compiler:

Well, that was a requirement for Phobos inclusion (and one that 
caused considerable complexity increase). The idea was to 
replicate the behavior of the original literal. Though I will 
grant the requirement that if the literal has a L on the end that 
it always comes out typed as long is what causes the effect you 
pointed out, since the compiler will treat that 10000000000 and 
10000000000L, and 10L too all the same way, so the template can't 
tell the difference.

Still, consider this massively simplified implementation:

enum o(ulong a) = to!int(to!string(a), 8);

That's consistently going to give you an int, even if the 
compiler made the input a long. But it no longer will give a long 
if you use the L suffix. (and yes i know it throws if the octal 
is legit more than 31 bits too, so you realistically might need a 
static if branch in there to allow that to be long in those 
cases. Or you could simply make it always return ulong and let 
VRP take care of things:

enum o(ulong a) = to!ulong(to!string(a), 8);

int x1=o!10000000000; // perfectly fine

but then `auto` will always give you ulong. so there is no 
perfect answer. only the string one can really match the suffix 
rules etc. or, of course, a built in literal. which is the 
correct answer. But I personally never liked the string version.

BTW there's also an argument to be made that the whole `enum` 
aspect is a bit hacky - you can also use a standard function and 
let the ordinary constant folder and dead code elimination give 
you the very same result too.)



like i get your point and you can call it a hack if you want

but i consider it pure genius

just like its brilliant inventor

it just isn't meant for this fallen world in which we live