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.

On 2/11/18 4:48 PM, Walter Bright wrote:
>> 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've never seen a hex dump where the individual nibbles were separated by spaces in odd ways.

In other words, what I was saying is that:

"\x12\x34"

could be written as:

x"1 23 4"

which is... odd. What it does is make it so you can't reuse the parsing code inside the string escape processor to handle the hex string, necessitating an extra 80-line function.

>> I wouldn't call invoking CTFE "no overhead"
> 
> It is no overhead in the generated code.

It's overhead that adds up, memory and time-wise. Really, the memory concerns of using CTFE are a bigger problem than the extra tenths of a second of compile time.

> 
>> 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.

Or a very large hex string (very feasible). But very true that there are mitigating methods that can be used.

>> 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.

In the past, we have not broken code, even when it depends on known bugs, if we can help it. But maybe if we can fix the bug I filed above, it won't matter.

>> 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.

Essentially, you have instantiated the template eagerly, which kind of, sort of, defeats the purpose of a template. Though, you still do get the benefit of code generation, it's just not an "open-ended" template that you can instantiate with any type. Perhaps we should be using this pattern all throughout phobos where strings are involved, since there are ever only 3 types you instantiate with.

> The solution here is not "incredible", it is just not obvious.

The solution isn't incredible, but the fact that this solution is the only way to get the CTFE-only code not to creep into your object file is a bit dissatisfying. You would think the linker/compiler would not inject the unused function into the object file without having to do this.

>> 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.

I think this is due to functions-that-aren't-used being included.

In other words, there was nothing inherent in the old library code that created a requirement for druntime to be included.

The bloat is also a deficiency of the compiler, not the code itself.

>> 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.

I missed the discussion (there are times where I can't pay attention to D for a month or so due to being busy). But in any case, sure I understand the "why", but the cost/benefit for me was not high enough, and in some aspects, it is all cost, no benefit.

In any case, it isn't a decision that needs to be reversed, as there is a workable solution in the library, even if it's sub-optimal. I just think it's not as beneficial as has been reported.

-Steve