String Interpolation

[Salih Dincer]

On Wednesday, 25 October 2023 at 15:05:52 UTC, Arafel wrote:
> On 25/10/23 13:29, Jonathan M Davis wrote:
>> IMHO, mixins should be explicit, obvious, and greppable, and 
>> adding a separate syntax for them which tries to hide them is 
>> going to make the language worse. However a string is 
>> generated, if the programmer wants to turn it into code, they 
>> should just use mixin, and if it's ugly, it's ugly, but at 
>> least it's clear what's going on.
>
> I agree, however the current options regarding string 
> interpolation seem to be suboptimal:
>
> 1. Get a string interpolation that doesn't get you strings, and 
> that needs support from the called function (or only work in 
> specific cases, not for `foo(string bar);`. You also can't 
> assign to string, nor use it in most libraries that don't 
> support it explicitly.
>
> 2. Use a library solution using string mixins (quite cumbersome 
> as a user, and probably also inefficient).
>
> 3. Introduce high level dependencies in the language itself, at 
> least to do the formatting.
>
> So I was just trying to brainstorm alternatives that would 
> allow a library solution.
>
> The biggest hurdle is accessing to the caller's scope, so far 
> only string mixins get that. There could be perhaps a different 
> feature that does it, i.e. a way to define a (compile time) 
> function that get access to the caller's scope, but I'm not 
> sure we would actually want that.

Leave these library solutions aside and turn them into a language 
conduciveness integrated into the compiler.  Do you remember 
there was an x ​​in D1 time?

```d
// D1:
   writeln(x!"e697a5 e69cac e8aa9e"); // 日本語
// D2:
   auto data = hexString!"e697a5 e69cac e8aa9e";
```

SDB at 79