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

[Steven Schveighoffer]

On 2/6/20 2:00 AM, 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.

By that logic, associative arrays are not predictable, as most of the 
API for it is in object.d

Neither is Object comparison (object.opCmp)

This argument is bunk. If it's part of the spec, it's predictable, no 
matter if the compiler implements it or the library does.

> Template instantiations are a LOT slower than direct 
> implementation. Lots of interpolated strings means lots of template 
> instantiations.

This is a good point. I'll add also that every string interpolation 
would result in a new type (which has a cost). I would like for a 
different way for this to work, and would be OK probably with a 
non-templated struct. Obviously, the template version provides more 
flexibility and power. But a non-template type with e.g. an array of 
strings and an array of format specifiers (all in ROM) would be 
sufficient for most cases. You'd probably have to include the fully 
generated string for the implicit casting.

One could also accept the interpolated string as a template parameter to 
get compile-time usage.

> Yes, it's also significantly more code to implement

It will be significantly more code for the library to implement if he 
has to parse the format string or add a special function to handle 
interpolation (because it doesn't follow the normal format for that 
domain, e.g. SQL).

> and there has to be 
> error recovery for when the template can't be found, and checks for a 
> rogue template.

These are solved problems. See all the templates inside the object module.

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

This is a fundamental disconnect. It's not ticking a box, it provides 
real value as described many times across this thread. You are willfully 
ignoring those points. And it's why I almost want to delete this 
message, and focus on more important things. But I'll send this last 
one, and then you can approve your own DIP without listening to the 
community.

-Steve