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:
>> [...]
>
> because
>
> string s = ("%s",var);
>
> is a syntax error.

Exactly. And then explain why. And what is that thing on the right. And why is string assignment not working on an interpolated _string_?

> Even a beginning programmer can understand that an interpolated string cannot be a pure simple string as it contains symbols and expressions that are language construct not part of the string literal, i.e. that the compiler has to perform some transformations to substitute these language symbols into a value.
> Interpolated strings, in any language, are not string literals.

In any language, they can be assigned to strings.

> Each language resolves this fact in different manners and at different times. Interpreted languages do it at runtime (obviously), java like languages chose to do it at runtime. In a language like D, which prefers resolving what is resolvable at compile time, it would be loathed if it interpolation was resolved at runtime (remember how long people were bitching about runtime only format strings?)
> Resolving interpolation at compile time is imho incompatible with handling them as regular strings.
>
> The question is then do we want CT or RT interpolated strings. RT interpolated strings can still be provided by a library.

See Adam's previous posts on his approach.

On Monday, 16 December 2019 at 11:18:33 UTC, Patrick Schluter wrote:

> 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.

Not sure how other languages do it but in Ruby the interpolation is performed where the string literal is declared. Not where the string is later used. So the above would fail because  `a` is not available.

--
/Jacob Carlborg

On Monday, 16 December 2019 at 11:38:34 UTC, aliak 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:
>>> [...]
>>
>> because
>>
>> string s = ("%s",var);
>>
>> is a syntax error.
>
> Exactly. And then explain why. And what is that thing on the right. And why is string assignment not working on an interpolated _string_?
>
>> Even a beginning programmer can understand that an interpolated string cannot be a pure simple string as it contains symbols and expressions that are language construct not part of the string literal, i.e. that the compiler has to perform some transformations to substitute these language symbols into a value.
>> Interpolated strings, in any language, are not string literals.
>
> In any language, they can be assigned to strings.

Not true for some languages I checked

- C# and Kotlin do the resolution at runtime and the interpolated string is not a string and has to be converted with .toString which is equivalent in calling .format in D.
- Rust and Java do not have interpolated strings
- Swift I don't know. Looks powerful but in a whole different difficulty level.

all others are interpreters python, perl, ruby, bash, tcl, VB, PHP etc. for whom it is much easier as there is no distinction between CT and RT.


>
>> Each language resolves this fact in different manners and at different times. Interpreted languages do it at runtime (obviously), java like languages chose to do it at runtime. In a language like D, which prefers resolving what is resolvable at compile time, it would be loathed if it interpolation was resolved at runtime (remember how long people were bitching about runtime only format strings?)
>> Resolving interpolation at compile time is imho incompatible with handling them as regular strings.
>>
>> The question is then do we want CT or RT interpolated strings. RT interpolated strings can still be provided by a library.
>
> See Adam's previous posts on his approach.
// Use reduce to calculate the sum
    // of all squares in parallel.
    auto result = taskPool.reduce!"a+b"(
        0.0, iota(100).map!"a*a");
    writeln("Sum of squares: ", result);

On Monday, 16 December 2019 at 12:43:04 UTC, Patrick Schluter wrote:

> // Use reduce to calculate the sum
>     // of all squares in parallel.
>     auto result = taskPool.reduce!"a+b"(
>         0.0, iota(100).map!"a*a");
>     writeln("Sum of squares: ", result);

Ignore that random crap at the end of my post. It was a copy paste accident.

On Monday, 16 December 2019 at 12:37:47 UTC, Jacob Carlborg wrote:
> On Monday, 16 December 2019 at 11:18:33 UTC, Patrick Schluter wrote:
>
>> 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.
>
> Not sure how other languages do it but in Ruby the interpolation is performed where the string literal is declared. Not where the string is later used. So the above would fail because  `a` is not available.
>
Yes, probably. The issue I had with the transformation as string is what should the code below print?

import fn;

int a, b = 20;

string inter = i"$(a+b)";

for(a=0; a<10; a++)
   fn(inter);

 ---
 module fn;

 void fn(string s)
 {
   writef(s);
 }

prints
202020202020202020

or

212223242526272829

and that's the difference between CT evaluation and RT evaluation.

On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
> On Monday, 16 December 2019 at 01:35:51 UTC, Walter Bright wrote:
>> On 12/15/2019 2:17 AM, Aliak wrote:
>>> To use it people will need to understand how to use d tuples as well.
>>
>> No, they don't.
>
> User: why can't I do this?/Why doesn't this work?
>
> string s = i"$var";
>
> Answer?

import std.format: format;
string s = format(i"$var");

On Saturday, 14 December 2019 at 07:34:05 UTC, Walter Bright wrote:
> I don't see the point of that. The user could write it that way to begin with.

Translations. Marking all your sentence fragments as translatable is messy, but there's a far worse impact on translators.

They will have some trouble piecing together the sentence, then they will find it almost impossible to translate the fragments in the correct order for the data arguments. Spoken languages are not word for word equivalent.

On Monday, 16 December 2019 at 12:43:04 UTC, Patrick Schluter wrote:
> On Monday, 16 December 2019 at 11:38:34 UTC, aliak wrote:
>> On Monday, 16 December 2019 at 11:08:00 UTC, Patrick Schluter wrote:
>>> [...]
>>
>> Exactly. And then explain why. And what is that thing on the right. And why is string assignment not working on an interpolated _string_?
>>
>>> [...]
>>
>> In any language, they can be assigned to strings.
>
> Not true for some languages I checked
>
> - C# and Kotlin do the resolution at runtime and the interpolated string is not a string and has to be converted with .toString which is equivalent in calling .format in D.
> - Rust and Java do not have interpolated strings
> - Swift I don't know. Looks powerful but in a whole different difficulty level.

You can assign strings to interpolated strings in all these languages you mentioned that have interpolated string support

Kotlin:

var x = 3
var s: String = "$x" + "$x"

Swift:

let x = 3
let y: String = "\(x)"

C#
string n = "hello";
string x = $"{n}";

On Monday, 16 December 2019 at 13:22:45 UTC, Atila Neves wrote:
> On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
>> User: why can't I do this?/Why doesn't this work?
>>
>> string s = i"$var";
>>
>> Answer?
>
> import std.format: format;
> string s = format(i"$var");

That isn't an answer to the question, it's just a workaround. Interpolated strings could implicitly convert to strings, which is the most common use case in typical D code. That would not bloat code that doesn't need it, as Adam has shown by using an import inside a template.

Interpolated strings should not be designed with low-level concerns as the priority motivator at the cost of high level usability and safety.

D is supposed to be a type safe language, even std.format.format is not fully type safe because using string for a format string allows runtime errors.

Any good D interpolation proposal would support compile time checked format strings, even when runtime arguments are passed. D is supposed to be the best language for compile time stuff!

On Monday, 16 December 2019 at 13:22:45 UTC, Atila Neves wrote:
> On Monday, 16 December 2019 at 10:48:51 UTC, aliak wrote:
>> On Monday, 16 December 2019 at 01:35:51 UTC, Walter Bright wrote:
>>> On 12/15/2019 2:17 AM, Aliak wrote:
>>>> To use it people will need to understand how to use d tuples as well.
>>>
>>> No, they don't.
>>
>> User: why can't I do this?/Why doesn't this work?
>>
>> string s = i"$var";
>>
>> Answer?
>
> import std.format: format;
> string s = format(i"$var");

This is non obvious. And only explainable by mentioning tuples.