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.
