DIP 1027---String Interpolation---Community Review Round 1
schveiguy at gmail.com
Sat Dec 14 15:04:24 UTC 2019
On 12/14/19 9:23 AM, Adam D. Ruppe wrote:
> On Saturday, 14 December 2019 at 09:10:47 UTC, Walter Bright wrote:
>> I find your proposal a little confusing. By turning the string into an
>> object, it doesn't work with printf?
> Right, not directly. But then it is trivial to add a member of the
> object that transforms it into a tuple suitable for printf.
> So the end user's code now looks like: `printf(i"foo %bar".asFormatTuple);`
> BTW I am not opposed to your version either, since it can be transformed
> into something close to my version. My big concern is that your version
> (as well as Jonathan Marler's) loses information very easily.
What information does it lose?
> printf(i"%item"); // happens to work
> writefln(i"%item"); // also happens to work
> writeln(i"%item"); // oops! not going to do what you want
But did what you asked? Coding is full of such dilemmas. I've actually
done this many many times:
writeln("Value is %s", value);
I see the result, and fix it. This isn't difficult.
One other suggestion I had was to make the resulting string literal
generated by interpolation be a derivative of a string literal. That is,
it's usable wherever a string literal is, but functions that wish to
overload based on that type difference can do so.
i.e. we could make the writeln call above work as expected.
> format(); // works
> text(); // wrong
> And there's no compile error for incorrect usage. With an object, we get
> existing type checking safety and can guide it to the correct usage:
> printf(i""); // error cannot implicitly convert __d_interpolated_string
> to const char*
Hm... I prefer it just working correctly.
> writefln(i""); // static assert failed: "use i"".asFormatTuple instead
Same. But why wouldn't writefln be overloaded on your object type to do
the right thing?
> writeln(i""); // happens to just work because it calls toString
Sure, but if you are going through the trouble to deal with format
specifiers, I don't know why you'd want to support writeln out of the
box but not writefln.
Not only that, but now you have to pull a lot of the library into
druntime (std.format for example).
>> I'm also not sure it's a good idea to make this more powerful. As a
>> simple "replace the string with a tuple" its very easy to understand.
> Objects are easy to understand too. And easy to implement: on the
> compiler it is basically just `X!(your version)` instead of just plain
> `(your version)`.
What about the lifetime issues? An object is going to make a copy. Which
may not be correct or possible.
I do like two aspects of your proposal. First is that all the
information is available for further compile-time manipulation. Second
is that having a specialized type allows function overloading.
More information about the Digitalmars-d