On 9/11/22 16:00, Steven Schveighoffer wrote:

> I'm actually quite proud of the bit shifting code, I tried to find the
> most efficient/clever mechanism to test for a straight given a bitfield.
> Once I thought of it, it was simple to implement and understand:
>
> https://github.com/schveiguy/poker/blob/6f70cf7ca74e19e78b470f81640a3ce34a95d0d3/source/poker/hand.d#L245-L256

That's very clever! :)

Ali

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?

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

On Tue, Sep 13, 2022 at 01:43:44PM -0700, Walter Bright via Digitalmars-d 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?
[...]

Simple, use `_`:

	0b1001_0010_0100

This makes it immediately obvious exactly how many bits the literal occupies.


T

-- 
Javascript is what you use to allow third party programs you don't know anything about and doing you know not what to run on your computer. -- Charles Hixson

On Tuesday, 13 September 2022 at 20:43:44 UTC, 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?
>
> It's pretty clear the hex one is a long.

It just as easy with binary literals as D supports the _ delimiter 0xb0100100_10010010_01001001_00100100. You can use the _ as you prefer. It is actually irrelevant what you think, if D would have been a commercial project you would have supported it because some customers would have demanded it. You would put a student on it to implement it during a weekend for a few dollars and movie ticket.

I can't believe this discussion. Initial motivation was to save a few lines of code, now the discussion more or less like what color of your underwear that is the best.

On 9/13/2022 2:04 PM, Steven Schveighoffer wrote:
>> 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?

Ok, I'll rephrase that. How do you know when to stop?

There's a reason hex is so ubiquitous. It's compact. Binary literals beyond a few digits (8 max) are more or less unreadable. Yes, the _ can extend it to more digits before it becomes unreadable. (Even long hex numbers benefit from _, again, after 8 digits.)

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:
> But it doesn't disprove the fact that *sometimes*, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?