October 22, 2023
On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:
> On 21/10/23 19:10, Walter Bright wrote:
>> For DIP1027,
>> 
>> |int var = 67; auto s = format(i"whatever $var"); |
>> 
>> would be equivalent to:
>> 
>> |auto s = "whatever 67";|
>
> At which point it's barely an improvement overs what we can already do:
>
> ```
> int var = 67; auto s = mixin(i!"whatever $var");
> ```
>
> I'm not saving even one keypress, and readability isn't that much better either.
>
> And we'll end up with multiple string literals, like `r"` and `q"`, and then something called "interpolated string" that uses a very similar token `i"` but that can't be used as a string, not even in the most straightforward cases.
>
> Don't you think this will be unnecessarily confusing for users?
>
> That's why I prefer DIP1036 over DIP1027, or even YAIDIP.
>
> I understand that you don't want to make it implicitly convertible to strings. Fair enough, I'm sure there are solid reasons for that. But please, in that case, don't call it a "string", and also don't give it a string-like syntax.
>
> Perhaps "interpolated sequence" with a clearly differentiated syntax? That would describe the feature much better.

Agreed, it's misleading. In almost all languages in existence it is implied that you want a string. It's about ergonomics. It should be clearly stated that you do *not* get a string and have to do that yourself, or more convenient ways should be added to do what you want in 99% of cases.
October 22, 2023
On Sunday, 22 October 2023 at 12:22:00 UTC, Imperatorn wrote:
> On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:
>> On 21/10/23 19:10, Walter Bright wrote:
>>> For DIP1027,
>>> 
>>> |int var = 67; auto s = format(i"whatever $var"); |
>>> 
>>> would be equivalent to:
>>> 
>>> |auto s = "whatever 67";|
>>
>> At which point it's barely an improvement overs what we can already do:
>>
>> ```
>> int var = 67; auto s = mixin(i!"whatever $var");
>> ```
>>
>> I'm not saving even one keypress, and readability isn't that much better either.
>>
>> And we'll end up with multiple string literals, like `r"` and `q"`, and then something called "interpolated string" that uses a very similar token `i"` but that can't be used as a string, not even in the most straightforward cases.
>>
>> Don't you think this will be unnecessarily confusing for users?
>>
>> That's why I prefer DIP1036 over DIP1027, or even YAIDIP.
>>
>> I understand that you don't want to make it implicitly convertible to strings. Fair enough, I'm sure there are solid reasons for that. But please, in that case, don't call it a "string", and also don't give it a string-like syntax.
>>
>> Perhaps "interpolated sequence" with a clearly differentiated syntax? That would describe the feature much better.
>
> Agreed, it's misleading. In almost all languages in existence it is implied that you want a string. It's about ergonomics. It should be clearly stated that you do *not* get a string and have to do that yourself, or more convenient ways should be added to do what you want in 99% of cases.

Buddy, not every language should be a Java-like language, stop expecting that your usecase should be enforced to everyone
October 22, 2023
On Sunday, 22 October 2023 at 17:37:23 UTC, ryuukk_ wrote:
> On Sunday, 22 October 2023 at 12:22:00 UTC, Imperatorn wrote:
>> On Sunday, 22 October 2023 at 11:32:12 UTC, Arafel wrote:
>>> On 21/10/23 19:10, Walter Bright wrote:

> Buddy, not every language should be a Java-like language, stop expecting that your usecase should be enforced to everyone

Hey buddy, nice to hear you're doing fine
October 22, 2023
On Saturday, 21 October 2023 at 12:44:51 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Doing so ties it to a specific formatting library.
>
> Which isn't acceptable, we need to remove coupling between the language and druntime let alone Phobos. Its nothing but trouble coupling the language to a library especially for a language feature which doesn't need to be.

If the string conversion function is a template then there's no dependency unless it is actually needed. Allocating a string is a fundamental part of D. Wanting a string from an interpolated string is likely the most common case. Doing this must not require importing a function from anywhere, otherwise I might as well not use an interpreted string and save myself writing an import. So at minimum, the interpolated string must support a method suffix to request a string. That method can be a template so interpolated strings can still be used in @nogc, betterC, etc.
October 22, 2023
On Sunday, 22 October 2023 at 20:21:54 UTC, Nick Treleaven wrote:
> Wanting a string from an interpolated string is likely the most common case.

What's your evidence for this?
October 22, 2023
On 22/10/23 22:44, Adam D Ruppe wrote:
> What's your evidence for this?

There's obviously no scientific evidence, because I don't think anybody has researched the topic.

But as an example, and perhaps ironically, let me point you to none other than yourself (or at least something co-authored by yourself). From [DIP1036](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1036.md#description):

> The primary use case is to employ the literal in place of a string-yielding expression:
>
> ```d
> void foo(string s);
>
> foo(i"Hello, my name is ${name} and I am ${age} years old.");
>
> string s = i"${var1} + ${var2} = ${var1 + var2}";
> ```

Other than this, I would say that the fact that most (all?) languages that support string interpolation allow implicit conversion to string (or whatever other way of seamless replacing a string with an interpolated string) should be a really strong hint.

Is there even any counter-example, i.e. any language where an interpolated string cannot be used anywhere a regular string would be used?

Now, don't misunderstand me. I get that there are good reasons why it might not be desirable to have this behaviour in D. But then please just don't use a misleading name and syntax that will run opposite to most people's expectations, unless you want to keep explaining to new users that:

```d
string rs = r"This a string";
string qs = q"(This also is a string)";
//string is = i"This is an interpolated string, absolutely not a string";
```

And why you need to call `format` (DIP1027) / `text` (YAIDIP) in that case.
October 22, 2023

On Sunday, 22 October 2023 at 21:32:15 UTC, Arafel wrote:

>

On 22/10/23 22:44, Adam D Ruppe wrote:

>

What's your evidence for this?

There's obviously no scientific evidence, because I don't think anybody has researched the topic.

But as an example, and perhaps ironically, let me point you to none other than yourself (or at least something co-authored by yourself). From DIP1036:

>

The primary use case is to employ the literal in place of a
string-yielding expression:

void foo(string s);

foo(i"Hello, my name is ${name} and I am ${age} years old.");

string s = i"${var1} + ${var2} = ${var1 + var2}";

FWIW, that is something Adam opposed, but I insisted on. I did not think a String Interpolation DIP would be viable without it.

I still feel like one should be able to use an interpolation tuple as a string, but it's really hard to come up with a design that doesn't feel like a complete hack.

It's indeed much much simpler to just push that requirement to build a string if desired on the user.

-Steve

October 22, 2023

On Sunday, 22 October 2023 at 21:55:23 UTC, Steven Schveighoffer wrote:

>

On Sunday, 22 October 2023 at 21:32:15 UTC, Arafel wrote:

>

On 22/10/23 22:44, Adam D Ruppe wrote:

>

What's your evidence for this?

There's obviously no scientific evidence, because I don't think anybody has researched the topic.

But as an example, and perhaps ironically, let me point you to none other than yourself (or at least something co-authored by yourself). From DIP1036:

>

The primary use case is to employ the literal in place of a
string-yielding expression:

void foo(string s);

foo(i"Hello, my name is ${name} and I am ${age} years old.");

string s = i"${var1} + ${var2} = ${var1 + var2}";

FWIW, that is something Adam opposed, but I insisted on. I did not think a String Interpolation DIP would be viable without it.

I still feel like one should be able to use an interpolation tuple as a string, but it's really hard to come up with a design that doesn't feel like a complete hack.

It's indeed much much simpler to just push that requirement to build a string if desired on the user.

-Steve

or improve the language, so we can express what we want in a library.
something like this:

writeln(mixin("5, 7"));
```
and

mixin(string) nothing(string s)() { return s; }
writeln(nothing!"5, 7");


and i don't know if that would work either, but there should be _some_ way to make it possible to implement every form of interpolation exactly like YAIDIP or DIP1027 work completely in library code. bonus, this might be useful for other this too.
October 22, 2023

On Sunday, 22 October 2023 at 22:57:30 UTC, duckchess wrote:

>

or improve the language, so we can express what we want in a library.

That's what the enhanced interpolation implementation does.

https://github.com/adamdruppe/interpolation-examples

Look down the examples here (and I have more coming as i find time to write them). How would you do them with your proposal?

October 23, 2023

On Sunday, 22 October 2023 at 23:44:34 UTC, Adam D Ruppe wrote:

>

On Sunday, 22 October 2023 at 22:57:30 UTC, duckchess wrote:

>

or improve the language, so we can express what we want in a library.

That's what the enhanced interpolation implementation does.

https://github.com/adamdruppe/interpolation-examples

Look down the examples here (and I have more coming as i find time to write them). How would you do them with your proposal?

    /** make this work **/
    writefln(mixin(`InterpolationHeader!("", "greeting", ", ", "name", "", "exclamation", "")(), "", greeting, ", ", name, "", exclamation, ""`));

    /** so it becomes this **/
    writefln(InterpolationHeader!("", "greeting", ", ", "name", "", "exclamation", "")(), "", greeting, ", ", name, "", exclamation, "");

    /************************/

    /** then add smtn to D to automatically mix in strings at the call side **/
    mixin(string) t(string s)() {
        // todo: code that actually generates the return string
        return `InterpolationHeader!("", "greeting", ", ", "name", "", "exclamation", "")(), "", greeting, ", ", name, "", exclamation, ""`;
    }
    writefln(t!"$greeting, $name$exclamation");

    /** turns into **/
    writefln(mixin(`InterpolationHeader!("", "greeting", ", ", "name", "", "exclamation", "")(), "", greeting, ", ", name, "", exclamation, ""`));


    /************************/

    /** this is a sketch of how i'd like the default implementation for i to look **/
    mixin(string) i(string s)() {
        return q{(){
            struct RESULT {
            	string toString() const { return "....."}
                mixin(string) printfargs(){ return ".....");
            	mixin(string) seq(){ return `InterpolationHeader!("", "greeting", ", ", "name", "", "exclamation", "")(), "", greeting, ", ", name, "", exclamation, ""`;}
        	}
        	return RESULT();
    	}()}

    }
    writeln(i!"$greeting, $name$exclamation");
    writefln(i!"$greeting, $name$exclamation".seq);

again, idk if this specific idea works, but this is how i'd imagine usercode to look like

writeln(i!"Hello, $name! I liked DIP $dipNumber a lot.");
string result = i!"$name! See that DIP $dipNumber is easy to convert to string.";
writefln(i!"$name has $$wealth:%0.2f".seq);
printf(i!"$name is $age years old.\n".printfargs);
writeln(tr!("I, $name, have a singular apple.", "I, $name, have %d apples.", count));
writeln(tr!("I, $name, have a singular apple.", "I, $name, have $count apples."));