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

[Tove]

On Sunday, 2 February 2020 at 18:07:00 UTC, Dennis wrote:
> On Sunday, 2 February 2020 at 15:31:46 UTC, Tove wrote:
>> Implict conversion to string would trigger allocations! This 
>> is not an option, allocations has to be explict.
>
> Memory allocation is an essential tool to make many language 
> features like array literals and nested functions just work. 
> Because of the garbage collector, this can be `@safe` without 
> leaks too, which is a good quality of D.
>
>> It's the same design philosophy as with the 'in' operator, you 
>> shouldn't use 'in' with O(n) algos, because it looks like a 
>> deceptively cheap operation.
>
> `in` has worst-case time complexity O(n) for associative 
> arrays, and in many practical cases an O(n) linear scan is 
> faster than a complex O(log n) search algorithm. Also, the 
> concatenation operator ~ is O(n) and triggers allocations.

The point is, it should be a fast operation, my conclusion still 
stands.

> D is not C where every operation is supposed to compile to a 
> handful of machine instructions at most.
> If you write:
>
> string c = i"name: $firstname $lastname";
>
> I don't think anyone would expect this to be O(1) without 
> allocations and dislike the language for making this simply 
> work in the best possible way.
>
> If you want it to not work unless no allocations are made, you 
> can use @nogc.

Sure @nogc works fine, but sometimes you want to use gc and when 
you do, the language should help you to do the right thing.

while(...)
   my_fun(i"name: $firstname $lastname");

If my_fun takes a string this would be terrible code, it should 
not compile until you make a conscious choice:
a) Performance is not important for my app. -> Let's add 
toString()
b) Add a new overload to my_fun that can handle interpolated 
strings directly.