On 2/8/18 3:49 PM, Walter Bright wrote:
On 2/8/2018 10:42 AM, Steven Schveighoffer wrote:
On 2/8/18 1:25 PM, Walter Bright wrote:
"abc" is an array (it's an immutable(char)[]). There's no reason why
['a','b','c'] should be different than "abc" (other than the hidden
null character, which is irrelevant here).
['a','b','c'] is mutable, a string literal is immutable.
OK.
alias IC = immutable char;
ubyte[3] x = [IC('a'), IC('b'), IC('c')];
works just fine.
Perhaps the fact that using a string rather than an array causes code
to fail should be addressed?
That would be a language change proposal or bug report. By all means,
please do so.
https://issues.dlang.org/show_bug.cgi?id=18420
How can this be a huge simplification? I mean you already have code
that parses hex characters in a string array, all you need is one flag
that assumes all character pairs have been preceded by \x. I think
this will save probably 4 or 5 lines of code?
hexStringConstant() was 79 lines of code, not including comments and
blank lines.
My mistake, I assumed the code to parse hex digits would be reused
between both string parsing with \x escapes and the hex string parser.
I also notice that hex strings are not simply equivalent to strings with
\x in them -- the latter is more constrained, as it must be a pair of
hex digits per \x. hex strings allow spaces between them.
I also showed how:
x"deadbeef"
can be replaced with:
hexString!"deadbeef"
with no overhead.
I wouldn't call invoking CTFE "no overhead"
I tested it out, and generating a hex string of about 600 bytes took 3x
as long as using builtin hex strings.
If you hate typing hexString, you can always write:
alias x = hexstring;
and then you've got:
x"deadbeef"
x!"deadbeef"
which seems an inconsequential difference. (The generated code is the
same.)
Again, this is about the compile time penalty.
It also doesn't preclude at all someone writing library code to make
their own custom string syntax.
You're right it doesn't. But people don't do it, because it is neither
obvious that D can do such a thing (it relies on a combination of
features)
This isn't really about having hexString in phobos, I think it's fine to
have it, even if it's redundant, since it can be more customized than a
builtin language feature. All I was saying is that the language feature
and the library function are not mutually exclusive.
nor is it obvious how to do it correctly (as the earlier
hexString implementation shows and nobody seemed able to fix it but me).
Well, nobody asked :) Besides, it's still not "fixed", as it has the
same poor performance as the previous version. And the new version has
broken existing code.
What the update shows is that you have to jump through incredible hoops
to get the compiler not to include your compile-time only generation
code in the resulting binary.
What Phobos provides is working, professional quality code that should
serve as a user resource for "how to do things and how to do them right".
It worked before, pretty much at the same performance as it does now,
the mitigating features (using string literals instead of array
literals, splitting the implementation into hand written functions to
avoid the D template penalty) are a good demonstration at how much work
we have to do still on the CTFE front.
I.e. having hexString as a library function is a good advertisement for
what D can do. After all, how many languages can do this sort of thing?
And nothing has changed here, it's still a library function, as it was
before. I agree, it's great to have the ability to do library functions
that can do compiler features. But if you already have the compiler
feature, I don't see why we should remove it because a slower library
version exists.
If we did not have the feature in the language, and we were talking
about adding it, I'd totally be on the other side. In fact, it's a
motivating factor to make CTFE code compile faster as it takes away
arguments of adding more things to the compiler.
-Steve
