DIP 1027--String Interpolation--Final Review Discussion Thread

[FeepingCreature]

On Thursday, 6 February 2020 at 07:00:33 UTC, Walter Bright wrote:
> On 2/5/2020 1:15 AM, FeepingCreature wrote:
>> On Wednesday, 5 February 2020 at 09:11:20 UTC, Walter Bright 
>> wrote:
>>> On 2/4/2020 9:48 PM, FeepingCreature wrote:
>>>> This may sound trivial, but trivial syntax enhancements 
>>>> matter, especially for a "top-ten" feature like format 
>>>> strings.
>>>
>>> It's a fair point, but there's a cost to supporting this. 
>>> Nothing comes for free, and supporting everything is not 
>>> practical.
>> 
>> Okay, what actually is the cost of lowering to a template 
>> instantiation returning a type with an alias to a tuple, 
>> compared to lowering directly to a tuple? Is this 
>> significantly harder to implement and support?
>
> For one thing, it becomes part of the language specification. 
> It has to be documented and taught. It turns a simple feature 
> into a complex one. Having language semantics controlled by a 
> hidden template is not in any other part of D. It implies that 
> the behavior of interpolated strings is not predictable. 
> Template instantiations are a LOT slower than direct 
> implementation. Lots of interpolated strings means lots of 
> template instantiations.
>

Format strings force template instantiations anyways - even if 
you lower to a tuple. Consider the innards of format. Format 
strings *already* inescapably mean lots of template 
instantiations. One template instantiation on top of that isn't 
going to even move the needle. Furthermore, it actually improves 
the proposal by still allowing static type checking against 
format specifiers - which your tuple proposal does not allow, 
because the string is a runtime value. And yes, static format 
string checks cost templates, but this is something that everyone 
who works with format strings is already doing *anyways*. I'd 
rather D focuses its efforts on making templates fast rather than 
nursing a phobia against an integral, widely-used part of the 
language.

> Yes, it's also significantly more code to implement, and there 
> has to be error recovery for when the template can't be found, 
> and checks for a rogue template.

I don't understand the difficulty. Lookup should be module 
specific anyways? And I can't see error handling being more than 
a few lines to error out.

>
> All that has to be weighed against the benefit. Implementing 
> something just because it is feasible and ticks a box is not a 
> sufficient reason to do it. D must have smallish features that 
> are widely useful, not be a large collection of trivia.

D must have features that work as intuitively expected. The tuple 
proposal fails this test. Simplicity in a feature is not worth 
confusing the feature's users, especially when a moderate 
increase in complexity buys an order of magnitude increase in 
usefulness.