On 2/7/18 12:01 PM, Adam D. Ruppe wrote:
> On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
>> For the same reason why octal literals have been deprecated years ago:
>>
>> https://dlang.org/deprecate.html#Octal%20literals

Not even close. Octal literals are a disaster, because putting a leading 0 should never change the base of a number. Basically, causing bugs everywhere for a small corner case in the real world.

The octal literal library solution is good, and it's fine to have something in the library for this, as octal values are extremely rare to need.

But in this case, there is no ambiguity. x"..." is not obvious syntax for anything else. Not only that, but the code to parse hex data into a string is still in there for "\x..." So we didn't even remove anything significant.

>> The library solution works as well and it's one of the features that are rarely used and add up to the steep learning curve.

How so? If you see a hex string literal, you look it up, and now your learning curve is over.

> That's actually not the reason given. Octal literals had the stupid leading 0. We should have just made it 0o instead.

This has its own problems (e.g. 0O), but definitely would have solved the issue. However, octal numbers are way less common than strings of hexadecimal data bytes.

The difference for me isn't how the problem is solved, but that there was a problem for octals (error prone sinister errors) but there isn't/wasn't one for hex strings. Not only that, but the removal from the language doesn't really buy us any savings in the compiler. It's basically removing things for the sake of removing them.

> Similarly, I think the mistake of hex strings is that they are typed char[] instead of ubyte[]. Otherwise... they work ok.

Yes, they would be better as ubyte[], but this problem is not the end of the world. I don't consider it the same level as thinking 012 is 12.

-Steve

On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
> On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven Schveighoffer wrote:
>> Seems like the same code you would need to parse the first is reusable for the second, no? I don't see why this deprecation was necessary, and now we have more library/template baggage.
>>
>> -Steve
>
> For the same reason why octal literals have been deprecated years ago:
>
> https://dlang.org/deprecate.html#Octal%20literals
>
> The library solution works as well and it's one of the features that are rarely used and add up to the steep learning curve.

I, like Steve, disagree.
Coming from c/c++ (and some Java), this was really simple to understand:
x"deadbeef"
While this took a lot more time to understand:
hexString!"deadbeef"

For hexString, I had to understand that ! is for function template instantiation, and I also had to find out what library to import.

On Wednesday, 7 February 2018 at 19:25:37 UTC, Ralph Doncaster wrote:
> On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
>> On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven Schveighoffer wrote:
>>> Seems like the same code you would need to parse the first is reusable for the second, no? I don't see why this deprecation was necessary, and now we have more library/template baggage.
>>>
>>> -Steve
>>
>> For the same reason why octal literals have been deprecated years ago:
>>
>> https://dlang.org/deprecate.html#Octal%20literals
>>
>> The library solution works as well and it's one of the features that are rarely used and add up to the steep learning curve.
>
> I, like Steve, disagree.
> Coming from c/c++ (and some Java), this was really simple to understand:
> x"deadbeef"
> While this took a lot more time to understand:
> hexString!"deadbeef"
>
> For hexString, I had to understand that ! is for function template instantiation, and I also had to find out what library to import.

I just did a quick check, and with DMD v2.078.1, the hexString template increases code size by ~300 bytes vs the hex literal.  So yet one more reason to prefer the hex literals.

On 02/07/2018 09:01 AM, Adam D. Ruppe wrote:

> But for octal? It was a mistake. We should have just made it 0o.

It sounds so natural. I forgot; what was the argument against it?

Ali

On Wed, Feb 07, 2018 at 07:29:10PM +0000, Ralph Doncaster via Digitalmars-d wrote: [...]
> I just did a quick check, and with DMD v2.078.1, the hexString template increases code size by ~300 bytes vs the hex literal.  So yet one more reason to prefer the hex literals.

Arguably, this is a QoI issue.  We seriously need to take a closer look at the current implementation of templates and consider how to improve it.  There is definitely plenty of room for improvement.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.

On Wednesday, 7 February 2018 at 17:36:56 UTC, Seb wrote:
> Octal predates GitHub, hexString is new:

Yes, I know, I was there :)

Heck, in the hexString forum thread, I argued that people knowing this pattern is really useful because then they can do all kinds of custom literals like stripping hexdumps.

Back in the octal days, I was thinking we should replace several literals with the new pattern and do more user-defined stuff. Notice who is cited in this old article http://www.drdobbs.com/tools/user-defined-literals-in-the-d-programmi/229401068


But, in the years since, I've changed my mind... somewhat. The pattern is still good and it being customizable is awesome, but it is a minor hassle and even that minor hassle has hurt the use in practice, like in the druntime examples.

We can do user defined literals for base X if we need more. But since octal is used by operating system apis and that'd under phobos... the phobos solution isn't great. Hex strings I think are going to be basically the same in time. The library artifact will sit there, unused.

On Wednesday, 7 February 2018 at 19:38:35 UTC, Ali Çehreli wrote:
> It sounds so natural. I forgot; what was the argument against it?

0o was denied basically just because we felt it wasn't necessary to have in the language at all; that it was rare enough and the library *can* do it, so the library *should* do it.

And at the time, I totally agreed! And in some cases, I still do - I think D programmers ought to know the technique so they can use it for their own niches.

Just in the years since, we see `0x40; // octal 0100` instead of `octal!100` since the cost of the library import is higher than the cost of converting by hand to hex or binary, which are still built into the language.

On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven Schveighoffer wrote:
> Not even close. Octal literals are a disaster, because putting a leading 0 should never change the base of a number.

I agree the leading 0 is terrible. But that's not the real question here: it is 0o100 vs import std.conv. Note it isn't the syntax - octal!100 is quite nice to me - but rather the requirement to import.

That is why it isn't used in druntime... and low level code interfacing with external OS or hardware APIs are the most common place for octal, and also where we can't use it. I fear hex will fall into the same pit.

> This has its own problems (e.g. 0O)

That's why I specifically wrote `0o`. I wouldn't allow `0O`, just like D doesn't allow `1l`: "Error: lower case integer suffix 'l' is not allowed. Please use 'L' instead"

> The difference for me isn't how the problem is solved, but that there was a problem for octals (error prone sinister errors) but there isn't/wasn't one for hex strings.

You and I are on the same side :) I also think they should stay (I just want to see them retyped as immutable(ubyte)[] instead of immutable(char)[], we always cast anyway).

I'd repurpose the library hexString to actually read in hex dump, stripping offsets, etc, off. Demonstrate that you can strip other stuff from the string with CTFE as an example of what we can do so people can customize that (that's a big advantage of the function over the literal btw, you can feed stuff through ctfe modifier functions before it is parsed. Can't do that with a literal!)

But also keep the x"" literal for the simple cases we already have.

On 2/7/2018 8:05 AM, Adam D. Ruppe wrote:
> That's just because -betterC is buggy and extremely incomplete

Can you please provide a list of these issues, and file issues that aren't on bugzilla yet, and tag them with the betterC keyword?

I see only one:

https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D&list_id=219382

On Wednesday, 7 February 2018 at 23:30:57 UTC, Walter Bright wrote:

> Can you please provide a list of these issues, and file issues that aren't on bugzilla yet, and tag them with the betterC keyword?
>
> I see only one:
>
> https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D&list_id=219382

Don't search for "[betterC]".  Instead, use "betterC" (without the brackets).

https://issues.dlang.org/buglist.cgi?quicksearch=betterc&list_id=219390

We can't reliably rely on informal conventions.

Mike