Regarding the proposed Binray Literals Deprecation

[Timon Gehr]

On 10.09.22 04:17, Walter Bright wrote:
> On 9/9/2022 4:43 PM, Adam D Ruppe wrote:
>>> If you're using a lot of octal literals such that this is an issue, 
>>> one wonders, what for? The only use I know of is for Unix file 
>>> permissions.
>>
>> I keep hitting them in random C code I'm translating. Various unix 
>> things beyond file permissions and a hardware manual for a think i had 
>> to drive (an rfid chip) used them for various bit triplets too.
> 
> octal!433 is really not much different from 0433. It could even be 
> shortened to o!433, exactly the same number of characters as 0o433.
> ...

o!422 is such a hack, and it does not even (always) work. This problem 
is even worse for binary literals.


> The reasons for adding language syntactic sugar:
> 
> 1. its very commonplace
> 
> 2. the workarounds are gross
> 
> Of course it's a judgement call, and I understand you see them randomly 
> in C code, but does it really pay off? The downside is the language gets 
> bigger and more complex, the spec gets longer, and people who don't come 
> from a C background wonder why their 093 integer isn't 93.
> ...

I think basically everyone here agrees that 093 is bad syntax and was a 
mistake.

>  > the newer imported!"std.conv".octal!433 pattern
> 
> Nobody would ever write that unless they used octal exactly once, which 
> suggests that octal literals aren't common enough to justify special 
> syntax.
> 
> 
>> I often prefer using binary literals anyway, but changing something 
>> like 0o50000 to binary is a little obnoxious.
> 
> I first implemented binary literals in the 1980s, thinking they were 
> cool and useful. They were not and not. I haven't found a reasonable use 
> for them, or ever wanted them. (I prefer writing them in hex notation, 
> as binary literals take up way too much horizontal space. After all, C3 
> is a lot easier than 11000011. The latter makes my eyes bleed a bit, too.)
> ...

Binary literals are e.g., a GNU C extension and they are in C++14, so 
clearly people see an use for them.

> Let's simplify D.

I really don't understand why you seem to think removing simple and 
convenient lexer features that behave exactly as expected in favor of 
overengineered Phobos templates that have weird corner cases and are 
orders of magnitude slower to compile is a meaningful simplification of 
D. It utterly makes no sense to me.

Let's simplify D in a way that actually positively impacts the user 
experience, for example by getting rid of weird corner cases and 
arbitrary limitations. Of course, that requires actual design work and 
sometimes even nontrivial compiler improvements, which is a bit harder 
than just deleting a few lines of code in the lexer and then adding ten 
times that amount to Phobos.