DIP 1027---String Interpolation---Community Review Round 1

Alexandru Ermicioi alexandru.ermicioi at gmail.com
Tue Dec 17 19:44:17 UTC 2019


On Monday, 16 December 2019 at 11:18:33 UTC, Patrick Schluter 
wrote:
> On Monday, 16 December 2019 at 11:08:00 UTC, Patrick Schluter 
> wrote:
>> On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
>>
>>> Resolving interpolation at compile time is imho incompatible
>> with handling them as regular strings.
>
> Maybe I'm wrong here, I haven't thought it through, but in 
> first approach I think that's an essential point. As the string 
> contains code, if evaluated at CT, the string must be split 
> somehow in literal parts and code parts. Allowing the i-string 
> to be handled as regular string implies that the splitting 
> happens sometime between when it is declared and after it is 
> used, which can happen after runtime.
>
> import fn;
>
> int b = 20;
>
> string inter = i"$(a+b)";
>
> foreach(a; 1..10)
>   fn(inter);
>
> ---
> module fn;
>
> void fn(string s)
> {
>   writefln(s);
> }
>
> How would that work?
>
> In python or javascript there's no issue, a is a runtime symbol.
>
>>
>> The question is then do we want CT or RT interpolated strings. 
>> RT interpolated strings can still be provided by a library.

Well there is a issue in javascript, interpolated string are 
evaluated once met in code by interpreter and are not somehow 
delayed at later stage as in your example.

Here is a test case:
```
var c = 40
var s = `${a + b} ${c}`

var a = 10
var b = 20
console.log(s)
```

The result is:
Nan 40

Best regards,
Alexandru


More information about the Digitalmars-d mailing list