DIP 1027, "String Interpolation", has been rejected. The decision was primarily influenced by the lack of consensus over the implementation and the syntax demonstrated in the two review threads. 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.

https://github.com/dlang/DIPs/blob/4be15bd40381667c0ab1c0aef360d0daa4b8c82c/DIPs/rejected/DIP1027.md

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.

On Sunday, 23 February 2020 at 18:57:55 UTC, Adam D. Ruppe wrote:
>> 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?


The one thing that MIGHT motivate this mistaken belief is if you think `foo` is defined in and looked up from random libraries.

That is NOT the case. `foo` here is a placeholder name for a template defined once and only once, in druntime. It is a normal lowering, just like is done very successfully in several places throughout the D language.

On 2020-02-23 16:22:46 +0000, Mike Parker said:

> DIP 1027, "String Interpolation", has been rejected. The decision was primarily influenced by the lack of consensus over the implementation and the syntax demonstrated in the two review threads. 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.
> 
> https://github.com/dlang/DIPs/blob/4be15bd40381667c0ab1c0aef360d0daa4b8c82c/DIPs/rejected/DIP1027.md 
> 

Out of curiosity, how and who makes such a decision? Is there a voting? Is there a committee? Is there a structured pro/con overview and highlight of blocking-points that need to be resolved?

I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all.

As a community with highly skilled people I think there should be a way to come to a good solution, not only a good enough. If not, this doesn't shed light on D and the community...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Sunday, 23 February 2020 at 18:57:55 UTC, Adam D. Ruppe wrote:
> 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.

I don't think that the proposed change was one small tweak. Even if it were, the DIP that just got rejected didn't have it.

There's also the practical question of template instantiations and compile times even if the DIP that was being discussed were to be modified in the way suggested.

Would you have preferred the DIP were accepted "as-was"?

On 2/24/2020 12:43 AM, Robert M. Münch wrote:
> Out of curiosity, how and who makes such a decision? Is there a voting? Is there a committee? Is there a structured pro/con overview and highlight of blocking-points that need to be resolved?

I talk it over with Atila after the review threads are done, then decide. Voting is a terrible way to do engineering design, for many reasons I can list if you like.


> I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all.

Not totally. I was unable to convince people that printf format validation was an orthogonal feature. So I went ahead and implemented that to show it had nothing to do with the proposal:

https://github.com/dlang/dmd/pull/10812

It turned out kinda sweet, and found a huge number of latent bugs in our own code, proving we shoulda done that long ago :-) Bad printfs turned out to be much more common than I'd anticipated.


> As a community with highly skilled people I think there should be a way to come to a good solution, not only a good enough. If not, this doesn't shed light on D and the community...

Community input is what the review threads are for. Consensus on a good solution did not emerge.

On Monday, 24 February 2020 at 08:43:57 UTC, Robert M. Münch wrote:

>> 
>
> Out of curiosity, how and who makes such a decision? Is there a voting? Is there a committee? Is there a structured pro/con overview and highlight of blocking-points that need to be resolved?

The DIP review process is outlined here:

https://github.com/dlang/DIPs

The final decision rests with the language maintainers. Now, that means Walter and Atila.

>
> I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all.

Not at all. In this case, as the DIP author, Walter could have chosen to revise the DIP with a new implementation. He chose not to. He wasn't persuaded by the arguments in the thread. Anyone else in the community is free to submit an alternative DIP for the same feature. Adam Ruppe has already done so:

https://github.com/dlang/DIPs/pull/186

If that proposal and its review manage to convince Walter and Atila, then the feature gets in.

>
> As a community with highly skilled people I think there should be a way to come to a good solution, not only a good enough. If not, this doesn't shed light on D and the community...

The DIP process is one way to approach that. It allows everyone to provide feedback and influence the drafting of the DIP. That requires convincing the DIP author to revise the DIP and ultimately convincing the language maintainers to accept it. It means there's a high barrier for acceptance, but in my own opinion that's how it should be.

On Monday, 24 February 2020 at 10:02:26 UTC, Mike Parker wrote:
>> I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all.
>
> Not at all. In this case, as the DIP author, Walter could have chosen to revise the DIP with a new implementation. He chose not to. He wasn't persuaded by the arguments in the thread.

Yeah, not to mention that in first place I think that he made a DIP for named args because the commuity was unable to formulate a good propostion, while he was himself not "pro-named args"... (maybe, I think i read this in the past)

On Monday, 24 February 2020 at 08:43:57 UTC, Robert M. Münch wrote:

> I mean, people spend a lot of time thinking, making suggestions, etc. and the end result is: we now have nothing. Which, IMO is the worst result for all.

We don't have nothing. There's an option value of not making a decision at this time. Once you decide to go forward with a string interpolation proposal, you're deciding not to go forward with any other similar proposal for many years, or even forever. This is IMO a minor feature (not a big deal if we don't have it). If you're going to do it, do it right. In some cases, there's really no way to know until you have a formal proposal and discuss the heck out of it whether it's worth going forward.

On 2/24/20 4:38 AM, Atila Neves wrote:
> There's also the practical question of template instantiations and compile times even if the DIP that was being discussed were to be modified in the way suggested.

I want to actually explore this.

There would be one template instantiation (probably) per usage. Not only that, but the function being called would also have a separate template instantiation per usage. This could potentially explode code to undesirable levels.

However, we have some possible mitigation techniques. For example, writefln should validate the format specifiers against the parameters, and then call the real writefln with a format string literal.

Second, I would suggest revisiting the idea of "temporary templates" that I talked about here: https://forum.dlang.org/post/qrjls8$13je$1@digitalmars.com. If the "shim" call is inlined, and the template removed, then you are simply left with the call to the standard writefln.

This does not reduce compile-times. But I'm hoping we have an answer in the newCTFE update. We should really explore more ways to make generative code more palatable. This is D's strength.

I will also note that we did something very similar with switch(string), where prior to this the compiler did all the "heavy lifting" of generating the code to convert strings into integers. Now it's done via a template which accepts all the strings as parameters. I don't think it was a bad change, and I'm sure it increased compile times and compiler memory usage. We shouldn't shy away from this type of stuff, but rather invest in making it better.

Finally, I'd say that I would really prefer a tiny bit of compiler magic here. I would love for the template that defines the format string to devolve directly into a string literal if that's the usage -- potentially without actually instantiating the template. It can be a better option if we are super-concerned about template slowdown.

-Steve