On Tuesday, 2 February 2021 at 13:06:06 UTC, Andrei Alexandrescu wrote:
> Thought: std.bitmanip.bitfields has some gnarly code that generates shifting and masking code for bitfields. It would be great to show how that code is vastly improved by the DIP.

Indeed, yikes.

And all that CTFE ~ work... ctfe performs very poorly with ~. So it would be worth making the interpolation function (idup or whatever we call it) be sure to avoid that. Doing array copies into preallocated buffers (buffer[spot .. spot + what.length] = what[], spot += what.length) is *significantly* faster, you can double or triple the speed of builds and cut dmd memory use down by 10x with those simple changes if you use the concated mixins heavily (my little jni.d did it like this at first and I did realize such enormous gains there, it was incredible).

That's fairly easy to do with the dip too since 1) the string literal pieces themselves are all known at compile time and 2) the length and types of the argument tuple is also known ahead of time, so you can use a static array to cache their intermediates (as necessary) while gathering their runtime lengths for the final copy.

If I can find some time later today I'll see what I can do with it.

On 2/2/21 1:22 AM, Walter Bright wrote:
> On 1/31/2021 3:04 AM, claptrap wrote:
>> Why is "working with printf" so important?
> 
> It's a canary. printf has a very simple interface, and if string interpolation doesn't work for simple cases, it is indicative of complexity problems.

To me this sounds like the wrong litmus test.

printf: separate format from data

interpolation: mix format with data

It doesn't seem to me at all that the first thing I'd want to do with interpolated strings is to contort them into a use of printf.

> Along with, of course, everybody uses printf and printf-style functions (dmd has many), and writef also uses a printf-style format.
> 
> I emphasize that #DIP1027 knows nothing about printf or its formats, other than having the default format be `%s`. The default can, of course, be overridden.
> 
> Again, DIP1027 KNOWS NOTHING ABOUT PRINTF OR ITS FORMATS.

This is good. We'd do good to keep printf out of the interpolation discussion.

CODE GENERATION IS WHERE IT'S AT.

On Tuesday, 2 February 2021 at 13:28:52 UTC, Adam D. Ruppe wrote:
> On Tuesday, 2 February 2021 at 08:16:11 UTC, Max Haughton wrote:
>> Cheap solution: p"Blah blah {blah}" for printf style, i"xyz" for everything else?
>
> Or just a (zero runtime cost!) library function which is possible with the dip as-is. D excels at these things and there's no need to special case the compiler for it.
>
> [snip]

I feel like you or Steven provided an example of this before, but I can't recall where. Is it worth it to provide a simple example of it in the DIP?

On 2/2/21 8:06 AM, Andrei Alexandrescu wrote:
> On 2/1/21 12:52 PM, Adam D. Ruppe wrote:
>> On Monday, 1 February 2021 at 17:06:36 UTC, Paul Backus wrote:
>>> No, you've added an extra level of quoting by mistake.
>>
>> oh yeah, that's right.
>>
>> So we could prolly just define the stringof of interp to be slightly less crazy (the source version either being the proper fqn or the literal itself) and then there's no special case in mixin.
> 
> Thought: std.bitmanip.bitfields has some gnarly code that generates shifting and masking code for bitfields. It would be great to show how that code is vastly improved by the DIP.

Yes, that is a great idea for a use case. Thanks for the pointer!

-Steve

On Tuesday, 2 February 2021 at 06:22:11 UTC, Walter Bright wrote:
> On 1/31/2021 3:04 AM, claptrap wrote:
>> Why is "working with printf" so important?
>
> It's a canary. printf has a very simple interface, and if string interpolation doesn't work for simple cases, it is indicative of complexity problems.

Making the DIP work with printf wont make it work with all simple interfaces. So printf is not "a canary for simple interfaces". All it actually does is make it work with a very specific subset of "simple interfaces" at the expense of all others.

You solved the equations for one variable, but you still have 3 unknowns.


> Along with, of course, everybody uses printf and printf-style functions (dmd has many), and writef also uses a printf-style format.

I dont, I have a few custom wrapper functions for formatting floats, and i use writeln.


> I emphasize that #DIP1027 knows nothing about printf or its formats, other than having the default format be `%s`. The default can, of course, be overridden.
>
> Again, DIP1027 KNOWS NOTHING ABOUT PRINTF OR ITS FORMATS.

I dont like either proposal tbh.

On Tuesday, 2 February 2021 at 14:45:05 UTC, claptrap wrote:
> On Tuesday, 2 February 2021 at 06:22:11 UTC, Walter Bright wrote:
>> On 1/31/2021 3:04 AM, claptrap wrote:
>>> Why is "working with printf" so important?
>>
>> It's a canary. printf has a very simple interface, and if string interpolation doesn't work for simple cases, it is indicative of complexity problems.
>
> Making the DIP work with printf wont make it work with all simple interfaces. So printf is not "a canary for simple interfaces". All it actually does is make it work with a very specific subset of "simple interfaces" at the expense of all others.
>
> You solved the equations for one variable, but you still have 3 unknowns.
>
>
>> Along with, of course, everybody uses printf and printf-style functions (dmd has many), and writef also uses a printf-style format.
>
> I dont, I have a few custom wrapper functions for formatting floats, and i use writeln.
>
>
>> I emphasize that #DIP1027 knows nothing about printf or its formats, other than having the default format be `%s`. The default can, of course, be overridden.
>>
>> Again, DIP1027 KNOWS NOTHING ABOUT PRINTF OR ITS FORMATS.
>
> I dont like either proposal tbh.

Anyway you look at this it seems there's no clear concensus on how it should work.

I really want this to pass, but not if there are many corner cases and/or special rules to follow.

It should be as simple as possible while also being as powerful as possible. It's a tough balance.

On Tuesday, 2 February 2021 at 14:31:53 UTC, jmh530 wrote:
> On Tuesday, 2 February 2021 at 13:28:52 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 2 February 2021 at 08:16:11 UTC, Max Haughton wrote:
>>> Cheap solution: p"Blah blah {blah}" for printf style, i"xyz" for everything else?
>>
>> Or just a (zero runtime cost!) library function which is possible with the dip as-is. D excels at these things and there's no need to special case the compiler for it.
>>
>> [snip]
>
> I feel like you or Steven provided an example of this before, but I can't recall where. Is it worth it to provide a simple example of it in the DIP?

Ah, here it is
https://forum.dlang.org/post/ruuigk$1bp8$1@digitalmars.com

On Tuesday, 2 February 2021 at 18:41:37 UTC, Imperatorn wrote:
> On Tuesday, 2 February 2021 at 14:45:05 UTC, claptrap wrote:
>> [...]
>
> Anyway you look at this it seems there's no clear concensus on how it should work.
>
> I really want this to pass, but not if there are many corner cases and/or special rules to follow.
>
> It should be as simple as possible while also being as powerful as possible. It's a tough balance.

You don't need a clear consensus on this in order to pass, as you just need to convince two people here.
-Alex

On 2/2/2021 6:20 AM, Andrei Alexandrescu wrote:
> CODE GENERATION IS WHERE IT'S AT.

How is that different?

On Tuesday, 2 February 2021 at 23:06:00 UTC, Walter Bright wrote:
> On 2/2/2021 6:20 AM, Andrei Alexandrescu wrote:
>> CODE GENERATION IS WHERE IT'S AT.
>
> How is that different?

I think the point here is that it's not worth killing the golden goose just to have printf work easily - I personally think a solution is obviously possible even if not through this DIP.

Ergonomically doing code generation with format specifiers is just really really ugly and brittle. I feel similarly with printf although I still use it as writeln compiles to a remarkable amount of machine code.

One thing that's just struck me is that with move semantics this could have a bunch of potential GC usage eliminated for relatively little cost by using some structs in the right place.