Discussion Thread: DIP 1036--String Interpolation Tuple Literals--Community Review Round 2
Adam D. Ruppe
destructionator at gmail.com
Thu Feb 4 18:50:17 UTC 2021
On Thursday, 4 February 2021 at 17:50:56 UTC, Meta wrote:
> I think it comes down to, when people (primarily and especially
> new users) see "", they expect a string.
It isn't "", it is i"". Javascript programmers seem to be able to
figure out the concept that a different prefix may not yield a
string. I'm sure D programmers can figure it out too.
Now my view btw is I'm down to two options:
1) You *always* get the naked tuple. It never converts to string,
but of course, you can call a function to convert it to string.
int bar;
auto item = i"foo ${bar}";
typeof(item) == AliasSeq!(interp!"foo ", int);
string s = item; // compile error, type mismatch
This is what I already implemented so you can play with it
immediately.
2) You *never* get the naked tuple. It is immediately passed to
an object constructor. That object uses `alias toString this` to
handle the string conversions and functions that want the whole
thing just overload on that.
typeof(item) == InterpolatedObject!(interp!"foo ", int)
string s = item; // works under current rules because
InterpolatedObject has alias toString this.
Adding this to the existing implementation is fairly simple since
it is the same except a ctor wrapper and one more druntime type.
Pros of 1: maximum flexibility. It can do anything you can
imagine by function calls, delegating 100% to user libraries. No
unnecessary strings built.
Pros of 2: more traditional explanation, the implicit cast works
under existing language rules.
Cons of 1: if you want a string, you *must* ask for one.
Cons of 2: sacrifices whatever potential there was in alias, ref.
has quirks with inout, may not work in all cases with dip1000,
dip 25, etc. It is basically a 90% solution. Also will require
more library support (that toString has to call something, much
of that is already in druntime, or it could import Phobos, so it
isn't a big deal, but it does need to be there for the implicit
conversion to work).
I've lost interest in anything else.
More information about the Digitalmars-d
mailing list