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.

On 21/10/23 17:42, Commander Zot wrote:
> you are missing the point. if |i""| does behave differently from just |""| this will lead to a huge number of people being confused later. they should really both be strings, or i"" should not exist at all. if you want interpolated tuples don't call it string interpolation and use t"" instead. changing code from "" to i"" should not change it's behavior.

I also think that interpolated strings should behave like... well, strings. Anything else would break the principle of least astonishment, and it's not certainly what some people might expect, me among them. If you must do it, please just don't call it "interpolated **string**".

Be it Python, Perl, bash, C# and even JavaScript (AFAIK, I've got less experience there), when you interpolate a string you get... well, a string. Only JS is more flexible here, but by default you'll get a string.

Even if they are not strings under the hood, they should be implicitly convertible to strings, at least in the default implementation, so if I have:

```
void foo(string s);
```

I should be able to do:

```
foo(i"Hello, $(name)");
```

or whatever other syntax is agreed upon, I don't really care that much about the bikeshedding.

Of course it's going to allocate when used like this, but it is a _convenience_ feature... The same way appending to a slice might allocate, those worried about allocations or using @nogc will have to take care of this, it's just syntactic sugar, after all.

Now, if under the hood there is something that library authors can override, that would be cool, but this "something" could just be a templated struct with an alias this to string. AFAIK the more specific match to the struct would then be the preferred overload.

I know `alias this` is kind of frowned upon, but I think this kind of usage is exactly what it is useful for:

```
void foo(string s) { }
void foo(IS)(IS s) if (isInterpolatedString!IS) { }
```

If a library author doesn't want a raw string and only support a specific interpolated string format, they just need to remove the first overload.

On Saturday, 21 October 2023 at 16:30:07 UTC, Arafel wrote:
> On 21/10/23 17:42, Commander Zot wrote:
>> [...]
>
> I also think that interpolated strings should behave like... well, strings. Anything else would break the principle of least astonishment, and it's not certainly what some people might expect, me among them. If you must do it, please just don't call it "interpolated **string**".
>
> [...]

Agreed

On 10/21/2023 5:38 AM, Commander Zot wrote:
> can we please just have ```i"whatever ${var}"``` to return a fully interpolated string, not a tuple, not a template or anything.
> because the common use case is ```auto s = i"whatever ${var}";```,
> so maybe just lower it into ```format("whatever %s", var)```.

Better tuple support is in the cards for D. They should be pretty straightforward.

For DIP1027,

```
int var = 67;
auto s = format(i"whatever $var");
```
would be equivalent to:
```
auto s = "whatever 67";
```

I.e. there are two steps involved:

1. convert the istring to a tuple
2. convert the tuple to a string

Having them be two steps enables the user to insert step 2:

1. convert the istring to a tuple
2. modify the tuple
3. convert the tuple to a string

On Saturday, 21 October 2023 at 16:30:07 UTC, Arafel wrote:
> I also think that interpolated strings should behave like... well, strings. Anything else would break the principle of least astonishment, and it's not certainly what some people might expect, me among them. If you must do it, please just don't call it "interpolated **string**".

Agreed. There were advocates for such a thing in the original set of discussions (including myself), but I can safely say that it's best to completely give up on such an idea.

There's a lack of desire to make language features rely on the GC. There also seems to now be regrets that D even has DRuntime(?), so adding any extra features or reliance on it is an instant no-go?

Regrettably, -betterC seems to now be the de-facto design pillar for this feature. While I do understand the arguments on why we can't just have `string a = i"1 + 1 = ${1 + 1}"` work and we have to be super special, quirky, and different, it just kinda sucks overall.