Regarding the proposed Binray Literals Deprecation

[Timon Gehr]

On 10.09.22 19:43, Walter Bright wrote:
> On 9/10/2022 9:18 AM, Timon Gehr wrote:
>> o!422 is such a hack,
> 
> How so?
> ...

422 is a decimal literal. E.g., there is type deduction logic in the 
compiler:

```d
import std.conv: o=octal;

void main(){
     auto x0=o!1000000000;
     static assert(is(typeof(x0)==int));
     auto x1=o!10000000000;
     static assert(is(typeof(x1)==long));
}
```

It was never meant to be interpreted as octal, and it shows.

>> and it does not even (always) work.
> 
> You're referring to when it has too many digits, it has to be done as:
> 
>    o!"442"
> ...

Sure, for example. Pure, unadulterated incidental complexity. Now every 
D programmer has to know multiple details about this nonsense. No 
simplification was achieved.

I was objecting to the argument where you used the hack to claim it's 
not much more ugly. However, this hack should not exist and not be used.

> It would be interesting to see a proposal to improve this sort of thing.
> ...

Build it into the lexer using the canonical syntax.

>> Binary literals are e.g., a GNU C extension and they are in C++14, so 
>> clearly people see an use for them.
> 
> I implemented them back in the 80s as an extension, and nobody commented 
> on them. I never found a use.

Obviously you have been using them on a daily basis and are just lying 
to us so you can simplify the lexer. /s

(Actually, I can see no upside whatsoever. I imagine the lexer will just 
get a bit bigger, because it still has to give a nice error message 
saying to use the Phobos template instead.)

> As for seeing a use, seeing a use for them 
> and actually using them are different things.
> ...

People have been telling you they are actually using them. I think you 
should consider updating your wrong belief that nobody is actually using 
them. It seems quite rude to tell people that they are not actually 
using features that they themselves can see they are obviously using.

> D originally was embeddable in html. The compiler was able to extract it 
> from html files. I saw a use for it, but never found one. It was 
> dropped. Nobody commented on that, either.
> 
> 
>>> 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.
> 
> The idea is to have a simple core language, and have a way that users 
> can add features via the library.

You consistently argue against things like AST macros. I don't think you 
can have it both ways. There's value in the language providing obvious 
features as built-ins with standardized syntax. The features are the 
language and clean syntax is one of the things that people consistently 
bring up when they have to explain why they are using D. This becomes 
harder to uphold when you turn obvious code into logically inconsistent 
line noise for purely ideological reasons.

> For example, user-defined literals are 
> a valuable feature. C++ added specific syntax for them. D has 
> user-defined literals as fallout from the template syntax.
> ...

D has templates with string arguments. I am pretty sure that even if C++ 
had templates with string arguments, they still would have added 
user-defined literals.

> User-defined literals in D are indeed an order of magnitude slower than 
> builtin ones. But that only matters if one is using a lot of them. Like 
> having files filled with them. How often does that happen?
> ...

It adds up. It opens the language up to ridicule. The cost/benefit 
analysis for removing this feature seems widely off.

> The Phobos implementation of octal is indeed overengineered, as I 
> mentioned in another post here. Phobos in general has been 
> overengineered, but that's not a fault of the language. I suppose I 
> should submit a PR to fix the octal template implementation.
> ...

I don't think there's a very good implementation of the idea.

> 
>  > 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.
> 
> We do this all the time.

Which is good.


Which situation is the simplest one?

a)

0x... for hexadecimal
0o... for octal
0b... for binary


b)

0x... for hexadecimal
std.conv.octal!"..." for octal
0b"..." for binary


c)

0x... for hexadecimal
std.conv.octal!"..." for octal
std.conv.binary!"..." for binary