DIP 1027---String Interpolation---Format Assessment

[Walter Bright]

On 2/27/2020 6:32 AM, Petar Kirov [ZombineDev] wrote:
> I'm not sure where exactly you draw the line, but I would say that C# follows 
> C's syntax about as much as D does.

C# is very different from C. D is not so different, and close enough that 
DasBetterC is very viable. Hindsight being 20/20, if I was doing a do-over with 
D I might even make it able to compile unmodified C code.


> Yet it doesn't import some of the broken C 
> semantics like implicit narrowing conversions (luckily, neither does D) and 
> allowing mixed sign comparisons (the oldest open D issue :( [0]).

I don't like C#'s solution to mixed sign comparisons for various reasons. Or 
Java's "solution", which is to not have unsigned types.


> My point is that if D didn't follow the usual arithmetic conversions, much fewer 
> newcomers would even notice compared to extremely large backlash that we may get 
> if go with the string interpolation -> raw tuple approach.

As opposed to backlash from another gc-required feature and low performance and 
not usable with printf nor writef nor any user-built functions like 
OutBuffer.printf and all the ones used by dmd.


> 1. Have a simple pragma(inline, true) wrapper function that will convert the 
> distinct type to printf-style args. This wrapper function can even be named 
> printf as it would work by virtue of function overloading. This is O(1) 
> additional code that once written no one will need to bother with.
>
> 2. Have the new type implicitly convert to printf-style args. I think this is 
> what Adam is proposing. While nice to have, I don't think it's necessary.

It's better to build things from simple components than try to break up a 
complex feature into components.


> As for std.stdio.write(f)(ln), there's no reason why any garbage would need to 
> be created, as again, a simple overload that accepts the distinct type will be 
> able to handle it just like it would (performance-wise) with DIP1027. However, 
> with DIP1027, only writef and writefln can be used, while write and writeln will 
> produce wrong results (wrong according to people that have used string 
> interpolation in other languages).

Magic types are not simple and inevitably lead to unexpected corners and 
unresolvable problems. *cough* associative arrays *cough*

You can have everything you want with DIP1027 interpolated strings by wrapping 
it in a function call to a function you specify. And so can everyone else.

DIP1027 will also likely lead to a number of unexpected treasures, as has 
happened repeatedly when simple building blocks were added, while complex ones 
just caused trouble.