September 12, 2022
On Friday, 9 September 2022 at 23:04:17 UTC, Walter Bright 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.

Also UTF parsing involves reflection on leading set bits to determine the number of code units.
Binary is more comfortable for unix permissions for me, whenever I see them in octal form I have to convert them to binary to make sense of them and then back from binary to octal to write them.
September 12, 2022

On Saturday, 10 September 2022 at 12:18:49 UTC, Paul Backus wrote:

>

They add a new token to the grammar, which means that tools like syntax highlighters have to be updated.

Obviously it's not a difficult change to make, but there is non-zero friction here.

In general yes, in this case (mostly) no. Most syntax highlighters use the fact that identifiers may not start with a digit. They interpret anything starting with a digit as a number up until a character that definitely isn’t part of a number like an operator or space. Even run.dlang.io does this. 03284FHKLLL.dfd.d..f_if is highlighted as if it were a number.

September 12, 2022

On Saturday, 10 September 2022 at 21:57:51 UTC, Timon Gehr wrote:

>

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

IF we get to this point, I’d want std.conv.hex!"..." just for sake of consistency.

September 12, 2022
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.
September 12, 2022
On Monday, 12 September 2022 at 14:48:12 UTC, jmh530 wrote:
>
> 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.

Common number literals should be a part of the compiler and not some kind of library. In the case of betterC you don't want to pull in Phobos just have simple number literals which will not even compile as a bare bone. BetterC will be used for near HW programming where binary literals are useful.

You talking about complexity and these are simple number literals. This thread has really made me lose faith in the D project all together. When you can't support simple things in the compiler, what happens with more complex features? Will you stand there with empty eyes as birdhouses? Painful thread for me it is.

September 12, 2022
On Saturday, 10 September 2022 at 14:50:18 UTC, rikki cattermole wrote:
> I'm still upset over hex strings.
>
> They were useful for generated files.
>
> https://raw.githubusercontent.com/Project-Sidero/basic_memory/main/database/generated/sidero/base/internal/unicode/unicodedata.d
>
> 2.72mb!
>
> It is an absolute nightmare to debug without hex strings

Can't you use escapes there?
September 12, 2022
On Saturday, 10 September 2022 at 18:14:38 UTC, Walter Bright wrote:
> Interesting that you brought up 7-segment display data, as I've actually written that stuff for embedded systems, and once again as a demonstration for the ABEL programming language.
>
> A couple things about it:
>
> 1. The visual representation of the binary doesn't have any correlation with how the display looks.

Dunno, I figured it out just by eyeballing it. Hex would be opaque.

> 2. It's a one-off. Once it's written, it never changes.

Perl style programming "write once and never touch" is sad, I try to write my code in auditable manner.
If I were to simplify D, I'd slay delimited strings, IIRC there are dozens of them.
September 13, 2022
On 13/09/2022 5:50 AM, Kagamin wrote:
> Can't you use escapes there?

Every character you add, increases the file size and slows down your editor.

Escapes require extra processing, more memory usage to display, which is unnecessary for this this type of data.
September 12, 2022
On Monday, 12 September 2022 at 17:56:42 UTC, Kagamin wrote:
> If I were to simplify D, I'd slay delimited strings, IIRC there are dozens of them.

There's three forms. All trivial lexer features that haven't changed for ages and not caused bugs in any other language component. While some editors might not support them properly, it isn't hard to add then forget about it.

September 12, 2022
On Monday, 12 September 2022 at 18:05:14 UTC, rikki cattermole wrote:
> Escapes require extra processing, more memory usage to display, which is unnecessary for this this type of data.

Hex strings require extra processing too, they aren't WYSIWYG. And there being lots of small code points I suspect you can even save space by using short escapes compared to hex strings.
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18