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.
