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

Adam D. Ruppe destructionator at gmail.com
Wed Feb 5 13:26:13 UTC 2020


On Wednesday, 5 February 2020 at 11:51:00 UTC, H. S. Teoh wrote:
> the interpolated string implicitly convertible to string)

That's actually not true. It will not implicitly convert because 
it is still a tuple. The first element is a struct with `alias 
this`, but I still recommend AGAINST that implicitly converting 
to avoid the `createWindow` problem described here: 
https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f#wrong-use-in-unrelated-function

However, I did allow it to implicitly convert to `const(char)*` 
(actually it prolly should be immutable, but meh) for purposes 
like `printf`, but if and only if you specify formatters for 
every item in the string. See: 
https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f#on-implicit-conversions

Instead of implicitly converting, you get a type error. I 
recommend the compiler special-case the type error to point users 
toward a web page explaining their options, one of which is an 
overload of `idup` in object.d 
https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f#diagnostics

This, I feel, is the best compromise between our opposing wishes 
as a diverse community:

1) It prevents common mistakes while still allowing some 
flexibility with legacy functions. You still *can* call `printf` 
incorrectly, but the short, convenient syntax will not allow it. 
This means you are less likely to accidentally send it on a wild 
pointer chase.

I personally think error checking is very important. D should not 
make the wrong thing easy.

2) It makes GC allocations explicit, yet convenient, with my 
proposed `idup` overload. If you just want to do

string s = i"whatever";

it will error and then you just slap `.idup` at the end, same as 
if you were assigning from a const char[] without worrying about 
performance details.

D users are no strangers to explicit extra calls for performance. 
See also: `.array` on ranges. People get used to it, then 
hopefully later learn why it does this and there can be better 
alternatives!

But here to be friendly to new users, I do want the special error 
message in the compiler telling people what they can do and why 
via web link. We do special error messages for `writeln` import 
missing for the same reason.

At the same time, D is supposed to be easy and many of us are 
perfectly OK with random GC allocations... and the .idup solution 
is close enough at very little - though admittably not zero - 
effort.

3) It makes other advanced uses range from very easy (if the 
library author utilizes the overload) to possible (user might 
need to specify strings or call other helper functions or write 
their own function depending on the exact circumstance).


More information about the Digitalmars-d mailing list