DIP 1027---String Interpolation---Format Assessment

[Adam D. Ruppe]

On Sunday, 23 February 2020 at 16:22:46 UTC, Mike Parker wrote:
> The decision was primarily influenced by the lack of consensus 
> over the implementation and the syntax demonstrated in the two 
> review threads.

That's not true, we had consensus minus one - the community 
rallied around just one small tweak to the proposal.

https://forum.dlang.org/post/r1emt0$2rpk$1@digitalmars.com "Now 
that is something I could use."

https://forum.dlang.org/post/gvckofpbecslxwlleynu@forum.dlang.org 
"This looks really good."

https://forum.dlang.org/post/bawaaxojdtvsguadefpc@forum.dlang.org 
"A different beast is Adam / Steven proposal ."

https://forum.dlang.org/post/mailman.1029.1580903463.31109.digitalmars-d@puremagic.com "Adam/Steven's proposal is *so* much better,"

https://forum.dlang.org/post/vhhumlsdimntzxnkxfbn@forum.dlang.org 
"hope we can get instead the proposal from Adam / Steven."

https://forum.dlang.org/post/oswkdwpocuvcvdrxpiag@forum.dlang.org 
"The implementation specified here is, more or less, what I would 
actually want out of string interpolation in D."

Each of those posts are from different people. And if you go 
through the thread, there's even more.

Sure, there's some people who would prefer % over $, or {} over 
(), or implicit over explicit toString/idup, but at the end of 
the day, we were all willing to put aside our remaining 
differences and accept that not 100% of people will be 100% happy 
to get a solution that 90% of people can be 90% happy with.

There's just one person who didn't appear to even engage with the 
idea. Guess who.

> As the DIP author, Walter also rejected the suggestion to go 
> with an implementation that resolves to a library template. He 
> sees that as equivalent to AST macros, a feature which he has 
> previously rejected.

How is `foo!str, args...` a macro when `str, args...` is not? 
Obviously, to the objective reader, neither is a macro - both are 
simply argument lists. Just one is (potentially) type-safe and 
the other isn't.