Regarding the proposed Binray Literals Deprecation

[Steven Schveighoffer]

On 9/13/22 4:43 PM, Walter Bright wrote:
> On 9/13/2022 1:06 PM, Steven Schveighoffer wrote:
>> If I wanted to specify an "every third bit set" mask, in hex it would 
>> be `0x924924924...`. But in binary it is `0b100100100100...`. The 
>> second version is immediately clear what it is, whereas the first is not.
> 
> Is it? How do you know it didn't overflow the int and create a long? How 
> do you know you filled up the int?

How do you know the purpose is to fill up an int?

> It's pretty clear the hex one is a long.

It's not a specific example with actual requirements for an existing 
problem. The point is that the sequence 924 isn't as clear that every 
3rd bit is set vs. 100.

Have you never started with "I need a number that has these properties", 
and then proceeded to build that number?

Like if you started with "I need a number that's all 9 digits in 
decimal" you wouldn't try to figure it out in hex, right? You'd just 
write 99999.... And if you need it to fit in an int, you figure that out 
(probably with trial-and-error). You don't start with "well, I can't use 
decimal, because then I'll never know if it fits in an int!"

Same thing with binary. It allows me to express *certain numbers* 
without thinking or figuring too hard. Like building a number that has n 
consecutive bits set (i.e. the poker example). Or if you have a register 
that has sets of odd-length bit patterns.

The list of things that it helps with is not large. It's also not 
completely eclipsed by hex. And unlike the horrible C octal syntax, it's 
not error-prone.

IMO, enough to counter any justification for removal, or hoisting into 
an expensive library implementation. It's not even a different *type*, 
it costs nothing, because everything happens in the lexer. Removing this 
feature is so insignificant in terms of compiler/language "savings", and 
significant in breaking existing code. It just shouldn't even be 
considered for removal.

-Steve