On Saturday, 12 September 2020 at 14:47:47 UTC, Andrei Alexandrescu wrote:
> On 9/12/20 9:44 AM, Paul Backus wrote:
>> // After
>> template Pack(Args...)
>> {
>>      alias expand = Args;
>> }
>
> Affirmative. We have that already: https://dlang.org/library/std/typecons/tuple.expand.html
>
> A dead simple Pack would have a good place in druntime and have Tuple be an elaboration thereof.

There's a version in std.meta, though it's currently marked as private:

https://github.com/dlang/phobos/blob/v2.093.1/std/meta.d#L1796

> I'd say don't complicate with that. Copy everything into the tuple. When one reaches for interpolated strings, it's not like they're hoping for a speed demon. Okay to draw the line at @nogc.

It's not really about speed, it's about making sure that code that *looks* equivalent actually *is* equivalent. Do we want to have to explain to users that these two lines of code, which do the same thing:

   writeln(i"Hello $name!".expand);
   writeln("Hello ", name, "!");

...actually have subtly different evaluation semantics, and that very occasionally they may have to stop think about whether they want the first or the second one?

This is the same kind of situation as C++ is in w.r.t. initialization, which has been described as a "nightmare". [1] Obviously the scale of the issue here is much smaller, but even small annoyances can add up over time.

[1] https://www.youtube.com/watch?v=7DTlWPgX6zs

On 9/12/2020 8:04 AM, Andrei Alexandrescu wrote:
> There is also a matter of being able to disagree strongly on something without that spilling into the personal. (Something my wife and I very much want to do in our own disagreements, with limited but notable success.) You and I work together. Steve and I are neighbors of sorts. I should be able to look you two in the eye and tell you, "this design sucks". And you should be able to tell me (hopefully not in retaliation), "autodecoding sucks". And we should all enjoy a drink of our choice together same as before.

I'll "heft a pint" to that!

Couldn't this be implemented entirely in library?

On Saturday, 12 September 2020 at 13:06:01 UTC, Andrei Alexandrescu wrote:
> On 9/12/20 5:27 AM, claptrap wrote:
>> On Saturday, 12 September 2020 at 02:48:38 UTC, Adam D. Ruppe wrote:
>>> On Friday, 11 September 2020 at 20:46:05 UTC, Paul Backus wrote:
>>>> This solves the issue of accidentally passing the wrong thing
>>>
>>> And processing an i"" is trivial; it is just either a string or a subclass of string (aka a struct with alias toString this) and you'd just use it like that.
>>>
>>> The t"" is more composable; it is the superior language feature. But I can live with a convenience compromise.
>>>
>>> So we'll see.
>> 
>> Thats a step in the right direction IMO.
>
> To me it seems akin to that moment you realize the practical joke has gone too far.
>
> Flight attendant: "More of anything?"
> Seinfeld: "More of everything!"
>
> So now we're talking about not one, but two interpolated strings. Deus Ex Machina and all that. (For fun and giggles: Good Work six months from now will make their semantics juuuuust slightly different.) How is this great design? There is so much to be said about sense and sensibility; living under one's means; economy of mechanism; creating a part of a whole; and such.
>
> I really feel we miss a different mind on the team. Someone who just thinks differently. Like an architect. Or a novelist.

One more interpolated string ... one more brain ... more of everything ;)

Maybe the problem isnot enough exploratory work is done up front? It's like evolutionary optimisation, if the initial set of solutions are not spread wide enough over the problem space you will inevitably converge on a local minimum instead of the global one.

I mean this DIP is a variation on Walters, Walters is an variation in writeln. They arnt really looking outside already established ideas for inspiration.

Its the convergent vs divergent thinking problem. And maybe programmers are very convergent in general, because you pretty constantly need to be evaluating what your doing as a programmer. So it's switch out of that way of thinking and just shoot ideas off with no criticism.

IE. Maybe have 4 or 5 people come up with as many solutions as possible, literally just write down ideas as they come to you. And then bring them all together and evaluate them. It's usually the outlier ideas that can spur people to "think differently" about the problem even if those outliers dont end up going anywhere.


> One possibility - which sadly comes from my limited engineering mind - is to create and observe budgets for metrics that are proxies to complexity.
>
> * 1000 words in the DIP
> * 1000 words complete documentation
> * 1000 words tutorial
> * 1000 lines in total implementation (compiler + library)
> * 30 seconds explanation that doesn't omit any dangerous subtleties

Im only going on what I see in the newsgroup but it often seems like everyone has their own set of goals by which to judge the DIP, instead of there being a document saying the DIP should meet these goals, specifying if a goal is an absolute or very desirable, or just nice to have. I it seems there's a jump straight from "we want string interpolation" to "heres a solution" and completely skip "what do we really want from string interpolation".

On Sunday, 13 September 2020 at 03:00:34 UTC, Yuxuan Shui wrote:
> Couldn't this be implemented entirely in library?

Yes, but not with exactly the same syntax. The library version looks like this:

writeln(mixin(i!"Hello $name!"));

On Sunday, 13 September 2020 at 10:20:19 UTC, Paul Backus wrote:
> On Sunday, 13 September 2020 at 03:00:34 UTC, Yuxuan Shui wrote:
>> Couldn't this be implemented entirely in library?
>
> Yes, but not with exactly the same syntax. The library version looks like this:
>
> writeln(mixin(i!"Hello $name!"));

That's not the same. mixin cannot create tuples.

On 9/12/20 10:48 PM, Walter Bright wrote:
> On 9/12/2020 8:04 AM, Andrei Alexandrescu wrote:
>> There is also a matter of being able to disagree strongly on something without that spilling into the personal. (Something my wife and I very much want to do in our own disagreements, with limited but notable success.) You and I work together. Steve and I are neighbors of sorts. I should be able to look you two in the eye and tell you, "this design sucks". And you should be able to tell me (hopefully not in retaliation), "autodecoding sucks". And we should all enjoy a drink of our choice together same as before.
> 
> I'll "heft a pint" to that!
> 

I suspect we shall be doing that in 2 weeks while discussing this DIP (hopefully updated)!

#beerconfsept

-Steve

On Sunday, 13 September 2020 at 13:03:23 UTC, Adam D. Ruppe wrote:
> On Sunday, 13 September 2020 at 10:20:19 UTC, Paul Backus wrote:
>> On Sunday, 13 September 2020 at 03:00:34 UTC, Yuxuan Shui wrote:
>>> Couldn't this be implemented entirely in library?
>>
>> Yes, but not with exactly the same syntax. The library version looks like this:
>>
>> writeln(mixin(i!"Hello $name!"));
>
> That's not the same. mixin cannot create tuples.

It potentially can, or at least wasn't that part of the rationale for deprecating the comma expression?

On Saturday, 12 September 2020 at 14:53:48 UTC, Adam D. Ruppe wrote:
> On Saturday, 12 September 2020 at 14:37:45 UTC, James Lu wrote:
>> [...]
>
> That's basically the C# solution.
>
> That is good if we just doing simple values, but it fails for D's unique compile-time things and is iffy with ref and non-copyable types.
>
> I wrote about it in more detail in my blog last year:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#hybrid-library-solutions
>
> In short, things like `ref`, `enum`, and `alias`-ness of data are lost through that layer.
>
> So good, but not great because it doesn't build on D's other existing strengths.
>
>
>
> Me and Steven continue to argue in a chat btw, we're whittling each other's ideas down and we're coming to something you all will prolly like...
>
> so stay tuned.

I don't know C# at all.

I have participated in Python language design discussions.

On Sunday, 13 September 2020 at 15:40:25 UTC, Jackel wrote:
> It potentially can, or at least wasn't that part of the rationale for deprecating the comma expression?

Yeah, maybe some day (and actually this DIP as written would be a practical tuple literal, though the more recent drafts we're throwing around are not anymore), but right now there isn't.

An AliasSeq comes close, but forces CTFE. A std.typecons.tuple comes close, but forces object member storage. A function parameter list might be closest but that's its own level of werid.

But yeah, a non-string tuple literal is perhaps something to explore separately too.