Jump to page: 1 213  
Page
Thread overview
DIP 1027--String Interpolation--Final Review Discussion Thread
Jan 30
Seb
Jan 30
Seb
Jan 31
Seb
Feb 02
Tove
Feb 02
bachmeier
Feb 02
Tove
Feb 02
Tove
Feb 02
Dennis
Feb 02
Tove
Feb 02
Dennis
Feb 03
Arine
Feb 03
Arine
Feb 04
jmh530
Feb 04
jmh530
Feb 06
Claude
Feb 06
Arredondo
Feb 04
jmh530
Feb 05
jmh530
Feb 05
Arine
Feb 05
Arine
Feb 07
matheus
Feb 07
jmh530
Feb 05
nullptr
Feb 04
Lim
Feb 04
Arine
Feb 06
aliak
Feb 06
nullptr
Feb 06
Lim
Feb 06
matheus
Feb 06
nullptr
Feb 06
Meta
Feb 06
matheus
Feb 07
Dennis
5 days ago
FeepingCreature
January 30
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
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
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
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
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
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
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
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
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
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