On 2/7/18 3:24 PM, Adam D. Ruppe wrote:
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.
So you think it should go into druntime? I don't see why it wasn't in
there in the first place to be honest.
But there is no "decision" on whether to import or not, it's not
possible in druntime to import from phobos. So saying the lack of use of
octal in druntime is somehow a detraction on the import is incorrect. If
you could have imported std.conv in druntime, it would have been done.
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"
I'm still not in love with the little-o syntax, but this definitely
would be necessary.
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).
To me, it is a shortcut for specifying hex for every character. The cast
isn't that horrible, and probably can be abstracted away into a function
if you want.
-Steve
