Regarding the proposed Binray Literals Deprecation

[Walter Bright]

On 9/10/2022 9:18 AM, Timon Gehr wrote:
> o!422 is such a hack,

How so?

> 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"

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

> 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. As for seeing a use, seeing a use for them and 
actually using them are different things.

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. 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.

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?

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.


 > 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.