Discussion Thread: DIP 1036--Formatted String Tuple Literals--Community Review Round 1

[SHOO]

On Friday, 11 September 2020 at 18:17:10 UTC, Adam D. Ruppe wrote:
> On Friday, 11 September 2020 at 17:37:36 UTC, SHOO wrote:
>> 2. It doesn't seem to work well with the {} style formatting 
>> employed by C#, Rust, etc. Is the following interpretation 
>> correct?
>> `String.Format("You are now {0} years old.", years - 1)`
>
> You'd do it more like
>
> `String.Format(i"You are now ${{0}}(years - 1) years old.")`
>
> No backslashes. But it isn't really ideal for positional ones 
> like that since you'd have to keep the count going right 
> yourself.
>
> At this point you would ideally write an overload to 
> String.Format that checks for the interpolation spec then 
> translates.
>
> The DIP's text as submitted right now makes this unnecessarily 
> difficult, so we're gonna reword it. The same implementation 
> still works though.

I understand.

>> 3. The object.idup in the DIP uses `import std.format`, is it 
>> permissible for the druntime to be dependent on Phobos?
>
> Technically, druntime is still independent. Since it is a 
> template, its dependency falls on the user, not the library.
>
> When you compile druntime, that code is completely ignored. It 
> is not present in the compiled library and the import is not 
> processed.
>
> If you use the idup function, the instance appears in *your* 
> code and only then is Phobos actually imported. So formally, 
> the dependency is on phobos from your code at the use point. So 
> if you never use it, there's no dependency.
>
> This is one of D's coolest features to me btw.

I am understanding that this is technically possible, but I am 
still skeptical of this. Whether or not it is technically 
possible and whether or not it is permissible as a policy are two 
entirely different things.
idup is part of the druntime. And idup uses std.format.
In general, this would be considered druntime is dependent on 
std.format.
It appears to be somewhat gray to claim that there is no 
dependency. I do not recommend doing anything gray.

>> 4. Are there any reasons why backquotes (i`...`) are not 
>> allowed?
>
> Trying to just define the simplest thing that can work. D has a 
> lot of string types and adding i to each of them is a lot.... 
> All these cases are possible with the juxtaposition thing 
> though:
>
> i""`....` would work the same way.

If there is no particular negative reason, I think it would be a 
better DIP to include it. The way i""`....` is written seems 
redundant.

Also, there is a history of concatenation when multiple string 
literals are written in succession, which has been previously 
deprecated. It seems to be a bad idea to adopt a similar method.

>> 5. Although you use the name idup, idup should be used to 
>> create `immutable(_d_interpolated_string!Parts)`
>
> There's two pieces to the interpolated tuple: the spec 
> definition and the arguments. The _d_interpolated_string!Parts 
> thing is just the spec definition. So your example is wrong: 
> you left the arguments out. idup makes no sense without 
> combining it.

Sorry, I was wrong. But my point is that converting to another 
type is the wrong feature of idup.

> The main reason for using idup over toString though is just 
> reusing an existing global name... it won't break any code 
> since it isn't introducing anything new. And since it already 
> works on string it has some precedent:
>
> char[] a;
> string b = a; // cannot convert, you need to idup it.
>
> string b = i"xxx"; // cannot convert, also need to idup it.

The following code will express my point better than above code:

string b = "xxx"w.idup; // cannot implicitly convert expression 
idup("xxx"w) of type wstring to string
string b = i"xxx".idup; // cannot implicitly convert expression 
idup(i"xxx") of type ?????? to string