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.

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

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

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.

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?

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.