Jump to page: 1 213  
Page
Thread overview
DIP 1027--String Interpolation--Final Review Discussion Thread
Jan 30, 2020
Mike Parker
Jan 30, 2020
Mike Parker
Jan 30, 2020
Seb
Jan 30, 2020
Sebastiaan Koppe
Jan 30, 2020
Adam D. Ruppe
Jan 30, 2020
Timon Gehr
Jan 30, 2020
Seb
Jan 30, 2020
MoonlightSentinel
Jan 31, 2020
Walter Bright
Jan 31, 2020
Walter Bright
Jan 31, 2020
Jonathan Marler
Feb 02, 2020
Walter Bright
Jan 31, 2020
Seb
Feb 02, 2020
Walter Bright
Feb 02, 2020
Adam D. Ruppe
Feb 02, 2020
Timon Gehr
Feb 02, 2020
Adam D. Ruppe
Feb 02, 2020
Tove
Feb 02, 2020
bachmeier
Feb 02, 2020
MoonlightSentinel
Feb 02, 2020
Tove
Feb 02, 2020
Adam D. Ruppe
Feb 02, 2020
Tove
Feb 02, 2020
Dennis
Feb 02, 2020
Tove
Feb 02, 2020
Dennis
Feb 02, 2020
Adam D. Ruppe
Feb 02, 2020
Adam D. Ruppe
Feb 02, 2020
Adam D. Ruppe
Feb 03, 2020
Arine
Feb 03, 2020
Adam D. Ruppe
Feb 03, 2020
Arine
Feb 03, 2020
Adam D. Ruppe
Feb 03, 2020
Adam D. Ruppe
Feb 04, 2020
Adam D. Ruppe
Feb 04, 2020
Adam D. Ruppe
Feb 04, 2020
Sebastiaan Koppe
Feb 04, 2020
jmh530
Feb 04, 2020
jmh530
Feb 04, 2020
Adam D. Ruppe
Feb 05, 2020
Jonathan Marler
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
Jacob Carlborg
Feb 05, 2020
Adam D. Ruppe
Feb 06, 2020
Johannes Loher
Feb 06, 2020
Sebastiaan Koppe
Feb 06, 2020
Claude
Feb 06, 2020
Jacob Carlborg
Feb 06, 2020
Adam D. Ruppe
Feb 06, 2020
Arredondo
Feb 04, 2020
jmh530
Feb 04, 2020
rikki cattermole
Feb 04, 2020
Timon Gehr
Feb 04, 2020
Johannes Loher
Feb 05, 2020
jmh530
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
Walter Bright
Feb 05, 2020
FeepingCreature
Feb 05, 2020
Walter Bright
Feb 05, 2020
rikki cattermole
Feb 05, 2020
Arine
Feb 05, 2020
Walter Bright
Feb 05, 2020
Johannes Loher
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
rikki cattermole
Feb 05, 2020
Arine
Feb 05, 2020
Adam D. Ruppe
Feb 07, 2020
Walter Bright
Feb 07, 2020
Adam D. Ruppe
Feb 07, 2020
matheus
Feb 07, 2020
Adam D. Ruppe
Feb 07, 2020
Adam D. Ruppe
Feb 07, 2020
jmh530
Feb 07, 2020
Adam D. Ruppe
Feb 05, 2020
Paolo Invernizzi
Feb 05, 2020
FeepingCreature
Feb 05, 2020
Paolo Invernizzi
Feb 05, 2020
Sebastiaan Koppe
Feb 05, 2020
Paolo Invernizzi
Feb 05, 2020
H. S. Teoh
Feb 05, 2020
Andre Pany
Feb 05, 2020
Adam D. Ruppe
Feb 05, 2020
nullptr
Feb 03, 2020
Sebastiaan Koppe
Feb 03, 2020
H. S. Teoh
Feb 02, 2020
Walter Bright
Feb 04, 2020
Lim
Feb 04, 2020
Jonathan Marler
Feb 04, 2020
Walter Bright
Feb 04, 2020
Jonathan Marler
Feb 04, 2020
Arine
Feb 04, 2020
Paul Backus
Feb 05, 2020
Walter Bright
Feb 05, 2020
FeepingCreature
Feb 05, 2020
Walter Bright
Feb 05, 2020
FeepingCreature
Feb 06, 2020
Walter Bright
Feb 06, 2020
aliak
Feb 06, 2020
FeepingCreature
Feb 06, 2020
Paolo Invernizzi
Feb 06, 2020
nullptr
Feb 06, 2020
Lim
Feb 06, 2020
matheus
Feb 06, 2020
nullptr
Feb 06, 2020
Meta
Feb 06, 2020
matheus
Feb 06, 2020
Adam D. Ruppe
Feb 05, 2020
Jesse Phillips
Feb 07, 2020
Dennis
Feb 19, 2020
dweldon
Feb 13, 2020
FeepingCreature
January 30, 2020
This is the discussion thread for the Final Review of DIP 1027, "String Interpolation":

https://github.com/dlang/DIPs/blob/d8f2e769c3a8c711e7886ccecc93eac9795dae9c/DIPs/DIP1027.md

This is the first review in which we are operating under the new procedure of using separate threads for discussion and feedback. Please see my blog post on the topic:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.

However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The review period will end at 11:59 PM ET on February 13, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Please stay on topic here. I will delete posts that are completely off topic.
January 30, 2020
On Thursday, 30 January 2020 at 09:46:38 UTC, Mike Parker wrote:

>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread.

The feedback thread is here:

https://forum.dlang.org/post/vhsfewrgycdeyynqdxnc@forum.dlang.org
January 30, 2020
On Thursday, 30 January 2020 at 09:46:38 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1027, "String Interpolation":
>
> https://github.com/dlang/DIPs/blob/d8f2e769c3a8c711e7886ccecc93eac9795dae9c/DIPs/DIP1027.md
>
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.

Well, I guess the discussions and reviews will continue to boil down around Walter's position for tuples:

> Much of the discussion revolved around the syntax and the choice of lowering to a tuple of format string and arguments, and questions about interaction with other language features (e.g., templates, token strings). The DIP author's position, established over several comments, was essentially:

>    tuples can easily be manipulated to suit the user's needs
>    the implementation must be compatible with BetterC, meaning printf and similar C functions
>    the implementation must not trigger GC allocations
>    the implementation must not depend on Phobos
>    the implementation must be performant

Structs are essentially just fancy tuples and look the same when stored in memory. Hence, I don't see why all of the above can't be done by a templated struct?
A templated struct would give the user a lot more options through additional opt-in methods and allow APIs to overload for them (e.g. SQL).
January 30, 2020
On Thursday, 30 January 2020 at 12:39:39 UTC, Seb wrote:
> Structs are essentially just fancy tuples and look the same when stored in memory. Hence, I don't see why all of the above can't be done by a templated struct?
> A templated struct would give the user a lot more options through additional opt-in methods and allow APIs to overload for them (e.g. SQL).

I reckon the answer is that it won't work with printf et al.

Which I find ironic because I believe the people who want interpolated strings most badly don't use printf at all.

That is of course always the problem of catering to a large group.

Still, it might just be that a templated struct will open up more options with more upside than the downside of it not supporting printf.
January 30, 2020
On Thursday, 30 January 2020 at 13:20:47 UTC, Sebastiaan Koppe wrote:
> That is of course always the problem of catering to a large group.

A struct is the best option for a large group since it can add methods to handle different scenarios.

Like I said in the last thread, it is fairly easy to make it work with a struct:

i"printf works too: %n2 %n\n".c.tupleof

Yes, you must call a method on it and explicitly do tupleof under current language rules. But it *is* possible and not even that weird.

And if you don't do that, the compiler will throw a helpful type error message that could even tell you what to do!

Then this is also possible several other things too. In my file, I also show that:

string s = i"..."; // just works, via `alias toString this;`
writeln(i"..."); // just works; writeln calls the toString method too

other_random_function(i"..."); // other_random_function can recognize the special type and do various library things to it too!

See my poc here: http://arsdnet.net/inter.d just pretend the `mixin(interpolate!(` wasn't there, since under the new DIP the language would do that part instead of the library.


We CAN have it all.
January 30, 2020
On Thursday, 30 January 2020 at 13:20:47 UTC, Sebastiaan Koppe wrote:
> On Thursday, 30 January 2020 at 12:39:39 UTC, Seb wrote:
>> Structs are essentially just fancy tuples and look the same when stored in memory. Hence, I don't see why all of the above can't be done by a templated struct?
>> A templated struct would give the user a lot more options through additional opt-in methods and allow APIs to overload for them (e.g. SQL).
>
> I reckon the answer is that it won't work with printf et al.

Yeah, but it would:

Option A) with .expand

printf(i"...".expand)

Option B) with an overload in druntime

int printf(InterpolatedString)(InterpolatedString str) {
   return printf(str.expand)
}

printf(i"...")


Both options would work in BetterC too.

> Which I find ironic because I believe the people who want interpolated strings most badly don't use printf at all.

+1


> Still, it might just be that a templated struct will open up more options with more upside than the downside of it not supporting printf.

+1
January 30, 2020
On Thursday, 30 January 2020 at 13:37:17 UTC, Seb wrote:
>
> Option A) with .expand
>
> printf(i"...".expand)
>
> Option B) with an overload in druntime
>
> int printf(InterpolatedString)(InterpolatedString str) {
>    return printf(str.expand)
> }
>
> printf(i"...")


Maybe even easier if dmd could handle a struct that decays into its members, e.g. an extended std.typecons.Tuple containing

alias expand this;

s.t. its members can be passed to printf & other functions automatically.

(I recognize that `alias this` should be used carefully but this would avoid declaring overloads for every function that accepts some format string)
January 30, 2020
On 30.01.20 14:34, Adam D. Ruppe wrote:
> 
> i"printf works too: %n2 %n\n".c.tupleof
> 
> Yes, you must call a method on it and explicitly do tupleof under current language rules.

Maybe not under future language rules:
https://github.com/tgehr/dmd/commit/bdb40fa96c471a7ace84596511a27ba3e803214f
January 30, 2020
On 1/30/2020 4:39 AM, Seb wrote:
> Structs are essentially just fancy tuples and look the same when stored in memory.

I've wanted to make tuples<=>structs. Here's the big problem - passing them as function parameters.

It just doesn't work and be compatible with the C ABI.
January 30, 2020
One unification I was able to achieve is to make structs and arrays equivalent.

Another is delegates unify class member functions, struct member functions, and nested functions.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11