Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[Adam D. Ruppe]

On Sunday, 13 September 2020 at 09:40:34 UTC, claptrap wrote:
> Maybe the problem isnot enough exploratory work is done up 
> front?

Various forms of this have come up over the years.

A PR in 2017 offered just the basics done automatically: 
https://github.com/dlang/dmd/pull/6703

This kind of thing is perhaps the most obvious - just have the 
compiler rewrite it for you. Very limited, though, it only really 
works for the one use case. Been discussed several times before 
this too, but never went anywhere.

This one in 2018 though opened up some new ideas, from Jonathan 
Marler:
https://github.com/dlang/dmd/pull/7988

The key innovation there was instead of calling a function, it 
just built an argument list. This is when these proposals 
actually started getting interesting to me: it makes it usable in 
a lot more cases, though the cost is it isn't as convenient. It 
is very simple though.

As you can see though, it got a great many comments and even a 
DIP draft <https://github.com/dlang/DIPs/pull/140/files>. In 
2019, Walter started thinking in terms of printf, and this 
eventually led to his DIP 1027, which had the compiler build a 
string and reorder the arguments for you. It is still a parameter 
list you just pass to another function, but it is partially 
cooked. This adds to the complexity but opened up more 
possibilities.

That's an interesting innovation too, but his DIP had a number of 
flaws and missed potential which this new DIP aims to patch. The 
major innovation here is adding a new type to the tuple.

Over the last couple days, we've had some new ideas came up and I 
considered what we could do with them.

Of course, there's a lot of other languages with things too, C# 
and Javascript both have quite interesting offerings, if you 
haven't looked at them, you should. The links are in the OP's 
references.


Anyway, meanwhile, Steven went back to the old ideas. So instead 
of adding new stuff, he shattered it and picked up just the 
pieces that survived. And what we're looking at now just takes 
the best one feature from each generation and puts it together. 
Convenience of gen one, flexibility of gen two, power of gen 
three. Without the rest of the accumulated cruft.

At first, I pushed back at him saying various use cases wouldn't 
work... but turns out they do. Much of the other stuff genuinely 
wasn't necessary. So we wrote the first several drafts and now 
are in the editing process to pare it back down.

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

Indeed, I often "think out loud" in these thread. Most of it goes 
nowhere... but every so often some piece of it endures. If we 
just instantly shot everything down instantly, we'd flush the 
gold with the dirt.