On 30/10/23 13:54, IGotD- wrote:
> Nor having any form of implicit conversions in the language is a limitation.

Oh, but we do: it's called "alias this".

It would be totally possible to lower the interpolation to a struct with an `alias this` that points to a default `toString` method that would do basic concatenation.

If you think it will help you secure your code, you can have your function **only** accept the lowered struct. Otherwise, you can have a string overload in addition to / instead of that.

If you don't care where your string parameter comes from, you just act as usual, keep using strings, and let the users construct them however they prefer.

Now, the usual argument against this is that it ties the "low level" compiler to a "high level" feature like string formatting (for floats, for instance).

I understand the concern. However, most of the code is already there used in `pragma(msg, ...)` and in `static assert`, so at most it would need to add a call to `toString` (if present) for aggregated types.

On Monday, 30 October 2023 at 16:43:14 UTC, Arafel wrote:
>
> Oh, but we do: it's called "alias this".
>
> It would be totally possible to lower the interpolation to a struct with an `alias this` that points to a default `toString` method that would do basic concatenation.
>
> If you think it will help you secure your code, you can have your function **only** accept the lowered struct. Otherwise, you can have a string overload in addition to / instead of that.
>
> If you don't care where your string parameter comes from, you just act as usual, keep using strings, and let the users construct them however they prefer.
>
> Now, the usual argument against this is that it ties the "low level" compiler to a "high level" feature like string formatting (for floats, for instance).
>
> I understand the concern. However, most of the code is already there used in `pragma(msg, ...)` and in `static assert`, so at most it would need to add a call to `toString` (if present) for aggregated types.

Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward. In 99% of the cases, you don't care what string interpolation is underneath and just want a string or parameter from it. The string interpolation implementation can even change over time.

On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:
> Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward.

This considered in my original proposal, 4 1/2 years ago:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal

On 30/10/23 18:37, Adam D Ruppe wrote:
> On Monday, 30 October 2023 at 17:26:27 UTC, IGotD- wrote:
>> Thank you for this and alias this wasn't even on my mind. We need more posts like this, solutions and how to move forward.
> 
> This considered in my original proposal, 4 1/2 years ago:
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_13.html#my-string-interpolation-proposal

Yes, I think I read it at the time, and it probably has unconsciously shaped my ideas, as have DIP1036 and YAIDIP (these two consciously).

Anyway, I went ahead and implemented a proof of concept, using mixins:

https://gist.github.com/erkrali/d48ed754b68a26e326b61aad78d43ab7

There's no documentation, but the code and unit tests should be quite clear. In short:

```d
foo (string s) { }
formatedFoo(IS)(IS is) if (isInterpolatedString!IS) {
	// Advanced formatting here
}

auto message = mixin(i!`Hello, $(name). Your balance is $({%f1.3}balance).`);
foo(message); // Works
formatedFoo(message): // Also works
```

The formatting part is optional and ignored in the default `toString` implementation, but still made available for libraries. The original strings representing the interpolated expressions are also made available.

Pros:

* Intrinsic cast to string.
* Can get a tuple to be used in `text` (shorthand: `mixin(it!"Hello, $(name)");`.
* In the struct you get all the existing information: The "static" text, the format string, the original symbol, and the value to interpolate.
* Can do overloads that unlock more advanced processing.
* Functions can choose whether to support only the advanced processing.
* It should be possible to use in -betterC as long as `toString` is not called, i.e. as long as only the `struct` or the `tuple` are used.

Cons:

* Well, it's a mixin. But that's just to show how it could look like.
* It's tied to `std.conv : to` for the default string conversion.
* The parsing probably stinks, has bugs, and is inefficient as hell. It could also eat your kittens. I'd assume that a "proper" implementation would be much better, but I don't have that much experience (if any at all) in this area.

So, all in all, it's just a proof-of-concept to show that it can really be done, and it's not just theory.