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

Adam D. Ruppe destructionator at gmail.com
Thu Feb 6 23:49:33 UTC 2020


On Thursday, 6 February 2020 at 10:53:18 UTC, Jacob Carlborg 
wrote:
> This will make it feel more like a real string.

It is not a real string. It is a string builder. They aren't 
supposed to feel the same.

Just like how `[1,2,3].map!whatever` doesn't actually run any 
code until you force evaluation with foreach, each, array, or 
something. I know it doesn't work that way in other languages, 
but it DOES work that way in much D code and there's good reasons 
for it.

That's my position and I'm sticking to it.


so a bit more explanation, really the thing is that implicit 
conversion is directly at odds against other use cases. We'd 
either sacrifice a few cases entirely or sacrifice some in part 
and require compiler magic to even make it possible.

Our options are:

1) Maintain my position. Conversion to string consistently 
requires an explicit call to `.idup` or another helper function. 
Everything else is possible with overloaded functions. Hits about 
10 / 12 user desires.

2) Switch to a C# style FormattableObject that implicitly 
converts to string. This sacrifices some use cases entirely 
(readf in particular, possibly interacting poorly wit `scope`, 
`return`, etc attributes as well), but may be more familiar to 
users coming from other languages. Hits about 8 / 12 user desires 
(though two of the hits here do include the misses in option #1)

3) Put magic into the compiler to automatically transform #1 into 
#2 depending on situation, or something like that. Will hit 11 / 
12 wishlist items, but at the cost of more compiler magic...

Hitting 12/12 is impossible because one of those items is 
implicit conversion to string and another one of those items is 
NO implicit conversion to string (for various reasons)!

So with those direct contradictions we just have to accept that 
100% of desires will NOT be 100% achieved.

My proposal gets us over 80% at a fraction of the cost of option 
#3; it is the 80/20 rule optimum in my view.


More information about the Digitalmars-d mailing list