Regarding the proposed Binray Literals Deprecation

[Don Allen]

On Monday, 12 September 2022 at 14:48:12 UTC, jmh530 wrote:
> On Sunday, 11 September 2022 at 07:24:03 UTC, Max Samukha wrote:
>> On Saturday, 10 September 2022 at 19:05:38 UTC, Don Allen 
>> wrote:
>>>
>>> I couldn't agree more with this. I've made it clear that I've 
>>> done some very successful work with D and have been very 
>>> pleased with the outcome. But this work involved porting C 
>>> code I wrote 10 years ago that had become ugly (or maybe it 
>>> always was) and difficult to maintain. The D version is a big 
>>> improvement.
>>
>> Removing the binary literals does not mean reduction in 
>> complexity, neither in the compiler, nor in the user code.
>
> There are multiple ways that complexity has been used on this 
> thread, which I think contributed to a lot of disagreements. It 
> might be better in the future if people make clear whether they 
> refer to compiler-complexity or user-complexity (or call it 
> developer-complexity, same idea).
>
> I don't have the knowledge to comment on how they impact 
> compiler-complexity.
>
> I think most people would agree that removing binary literals 
> would not meaningfully reduce user-complexity. I haven't heard 
> of a new D programmer struggling with understanding about how 
> binary literals interact with some other feature in a complex 
> way.  They aren't that frequently used, but people can look up 
> how they work if you need them. However, there's also an 
> asymmetry. The more a user makes use of them, the larger the 
> potential cost to them for the removal. So, even if there is a 
> minor reduction of user-complexity, the people who make use of 
> them face a larger cost. I think this is what frustrates some 
> on the thread.
>
> I would echo the comments of others about the importance of 
> automated tools to reduce the burden on users of these kinds of 
> changes. I don't recall anyone mentioning the removal of 
> complex/imaginary numbers, but the issues are the same.

On Monday, 12 September 2022 at 14:48:12 UTC, jmh530 wrote:
> On Sunday, 11 September 2022 at 07:24:03 UTC, Max Samukha wrote:
>> On Saturday, 10 September 2022 at 19:05:38 UTC, Don Allen 
>> wrote:
>>>
>>> I couldn't agree more with this. I've made it clear that I've 
>>> done some very successful work with D and have been very 
>>> pleased with the outcome. But this work involved porting C 
>>> code I wrote 10 years ago that had become ugly (or maybe it 
>>> always was) and difficult to maintain. The D version is a big 
>>> improvement.
>>
>> Removing the binary literals does not mean reduction in 
>> complexity, neither in the compiler, nor in the user code.
>
> There are multiple ways that complexity has been used on this 
> thread, which I think contributed to a lot of disagreements. It 
> might be better in the future if people make clear whether they 
> refer to compiler-complexity or user-complexity (or call it 
> developer-complexity, same idea).
>
> I don't have the knowledge to comment on how they impact 
> compiler-complexity.
>
> I think most people would agree that removing binary literals 
> would not meaningfully reduce user-complexity. I haven't heard 
> of a new D programmer struggling with understanding about how 
> binary literals interact with some other feature in a complex 
> way.  They aren't that frequently used, but people can look up 
> how they work if you need them. However, there's also an 
> asymmetry. The more a user makes use of them, the larger the 
> potential cost to them for the removal. So, even if there is a 
> minor reduction of user-complexity, the people who make use of 
> them face a larger cost. I think this is what frustrates some 
> on the thread.
>
> I would echo the comments of others about the importance of 
> automated tools to reduce the burden on users of these kinds of 
> changes. I don't recall anyone mentioning the removal of 
> complex/imaginary numbers, but the issues are the same.

I was talking about language complexity, as was Walter. I thought 
that was quite clear and still do.

While I expressed agreement with Walter regarding his desire to 
simplify D, I don't have a strong opinion about the possibility 
of removing binary literals, because this is not where I see D's 
complexity problems.

I don't use binary literals myself. A recent use case for me was 
defining various flag bits that are part of  integer columns in 
several Sqlite tables. I define them with enums like so:
````
enum AccountFlags
{
     descendents_are_marketable_bit = 0,
     descendents_are_marketable = 1,
     hidden_bit = 1,
     hidden = 1 << hidden_bit,
     descendents_are_assets_bit = 2,
     descendents_are_assets = 1 << descendents_are_assets_bit,
     placeholder_bit = 3,
     placeholder = 1 << placeholder_bit,
...
````
It's nice that the shifting takes place at compile-time in D.

Hardware registers usually are similar to the above -- a 
collection of bits each having its own meaning and a specific bit 
number. If I were doing this sort of work in D, I would most 
likely deal with those register bits in the same way I describe 
above. Creating masks for multi-bit fields can be dealt with 
similarly.

So while I don't have a personal use for binary literals, clearly 
others have. But Walter sees an internal cost to the compiler. So 
while most of us can weigh in on the perceived benefit of 
retaining binary literals or not, few of us can understand the 
cost and therefore the tradeoff.

I'd mention that Rust has binary literals as does Nim. Haskell 
does not, though it has both octal and hex literals.