On 2/11/2018 6:09 AM, Steven Schveighoffer wrote:
On 2/8/18 3:49 PM, Walter Bright wrote:
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
Good!
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.
The idea was to be able to cut&paste text from things like hex dumps, which
include whitespace formatting.
I wouldn't call invoking CTFE "no overhead"
It is no overhead in the generated code.
I tested it out, and generating a hex string of about 600 bytes took 3x as long
as using builtin hex strings.
That's only a potential issue if you've got a very, very large number of hex
strings. And if you do, those strings can be put in a separate module and
compiled separately.
Again, this is about the compile time penalty.
Ok.
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.
It didn't break code that used x"deadbeef", it broke code that used the broken
hexString.
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.
With a language that supports both templates and separate compilation, this will
always be an issue.
The solution here is not "incredible", it is just not obvious.
And nothing has changed here, it's still a library function, as it was before.
What's changed is it works now with -betterC, and it doesn't produce bloat in
the executable.
But if you already have the compiler feature, I don't see why
we should remove it because a slower library version exists.
It was not an arbitrary and capricious decision, and the rationale behind it was
presented here multiple times. If you are not convinced, that's cool, but the
"why" should be pretty clear.
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.
I agree that speeding up CTFE will make it more useful.
