October 27, 2023
On 27/10/23 11:30, IGotD- wrote:
> I've not been following the string interpolation debate because I'm not a big user of string interpolation but this made me wake up. Are you seriously proposing a design that cannot convert a string interpolated string into a regular string?

Yes, these are the current proposals.

Or at least not directly. You'll need to call a function for that.

So this will work:

```d
writeln(i"Hello, ${name}");
```

But this won't:

```d
string greeting = i"Hello, ${name}";
```

and you will need to do:

```d
string greeting = i"Hello, ${name}".text;
```

Walter's proposal is essentially the same in that regard, only using `writefln` and `format` instead of `write` and `text`.

Good luck explaining these subtleties to new / casual users.
October 27, 2023

On Thursday, 26 October 2023 at 16:25:26 UTC, Adam D Ruppe wrote:

>

On Thursday, 26 October 2023 at 16:14:08 UTC, bachmeier wrote:

>

Why not this?

https://en.wikipedia.org/wiki/String_interpolation#Security_issues

I'd argue that this is a problem of the sql library accepting a string in the first place, not a problem of string interpolation resulting in a string.
not having implicit to string conversion doesnt prevent someone from doing
sql_exec(i"...".text);

i would have prefered a way to write sql"" instead of sql!i"" but ultimately it doesn't matter that much.

the difference of your dip to macros is that we are stuck with whatever syntax we pick for the capture, so probably ${}, so not big of a deal.

and if we wanted we could still introduce a rewrite of sql"" into sql!i"" later.

October 27, 2023
On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:
>
> Yes, these are the current proposals.
>
> Or at least not directly. You'll need to call a function for that.
>
> So this will work:
>
> ```d
> writeln(i"Hello, ${name}");
> ```
>
> But this won't:
>
> ```d
> string greeting = i"Hello, ${name}";
> ```
>
> and you will need to do:
>
> ```d
> string greeting = i"Hello, ${name}".text;
> ```
>
> Walter's proposal is essentially the same in that regard, only using `writefln` and `format` instead of `write` and `text`.
>
> Good luck explaining these subtleties to new / casual users.

Can't this be solved by adding a constructor in the string class that accepts whatever type the interpolated string is?

October 27, 2023
On Friday, 27 October 2023 at 11:53:24 UTC, IGotD- wrote:
> On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:
>>
>> Yes, these are the current proposals.
>>
>> Or at least not directly. You'll need to call a function for that.
>>
>> So this will work:
>>
>> ```d
>> writeln(i"Hello, ${name}");
>> ```
>>
>> But this won't:
>>
>> ```d
>> string greeting = i"Hello, ${name}";
>> ```
>>
>> and you will need to do:
>>
>> ```d
>> string greeting = i"Hello, ${name}".text;
>> ```
>>
>> Walter's proposal is essentially the same in that regard, only using `writefln` and `format` instead of `write` and `text`.
>>
>> Good luck explaining these subtleties to new / casual users.
>
> Can't this be solved by adding a constructor in the string class that accepts whatever type the interpolated string is?

Would be nice yes
October 27, 2023

On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:

>

[snip]
Good luck explaining these subtleties to new / casual users.

We can add an error message when assigning to a string that tells the user to call .text or whatever if they want the string.

I tried to think of when I just want a string after doing interpolation (as opposed to writing immediately somehow) and struggled a bit. I think it would be usually in a string concatenation situation. So I asked Adam on his PR whether this works

auto x = 1;
auto y = 2;
auto s1 = i"The value of x is $x,";
auto s2 = i"and the value of y is $y.";
writeln(i"$s1 $s2");

and he says it does.

Something like writeln(s1, " ", s2) would also work.

October 27, 2023
On 27/10/23 13:59, Imperatorn wrote:
>     Can't this be solved by adding a constructor in the string class
>     that accepts whatever type the interpolated string is?
> 
> Would be nice yes
> 

Not possible. A string in D is just another name (literally, just an alias) for an array of immutable chars. So there is no string class, and no constructor to speak of, other than the generic array constructor.

Technically, the best solution would probably be to return a (templated) struct with an "alias this" to the already interpolated string, and all other interpolation information also included, so functions would be able to choose what to accept.

But "alias this" is just a way to have implicit casting, and that's something (probably rightly) opposed here on principle, so I don't think we'll be having it anytime soon.
October 27, 2023
On 10/26/23 20:10, Imperatorn wrote:
> 
> The users don't care at all about what's good or bad under the hood.
> 
> They just care about how they use something.
> 
> And having to do an extra step in one language but not all the other breaks the common interface.
> 
> It's nothing more than that. So simple.
> 
> It might turn out that string interpolation is not worth it in D. Ok, then that's a decision that could be made.
> 
> But that decision should be made after you understand the consequences.
> 
> Also saying that it's the users loss if they move to another language, I must ask, are you sure about that?

Pretty much. Personally, I care about technical superiority of D more than popularity of D. Why does D need users that push for features causing security vulnerabilities or badly handled file paths?
October 27, 2023
On Friday, 27 October 2023 at 12:49:24 UTC, jmh530 wrote:
> On Friday, 27 October 2023 at 09:47:15 UTC, Arafel wrote:
>> [snip]
>> Good luck explaining these subtleties to new / casual users.
>
> We can add an error message when assigning to a string that tells the user to call `.text` or whatever if they want the string.

But imagine that instead of "string" was "auto":

auto greeting = i"Hello, ${name}";

Maybe the user (Newcomer!?) is expecting a string in this "auto" greeting. The error message will be showed late only when the string conversion is expected not where was defined.

Matheus.
October 27, 2023
On 10/26/23 19:38, Imperatorn wrote:
>>
>> I'm sympathetic to not putting that functionality in the compiler.
> 
> And the users are not. That's all I'm saying.

I think it's a bit offensive to say people who do not agree with you are not users of the language.
October 27, 2023
On Friday, 27 October 2023 at 12:55:35 UTC, Arafel wrote:
>
> Not possible. A string in D is just another name (literally, just an alias) for an array of immutable chars. So there is no string class, and no constructor to speak of, other than the generic array constructor.
>
> Technically, the best solution would probably be to return a (templated) struct with an "alias this" to the already interpolated string, and all other interpolation information also included, so functions would be able to choose what to accept.
>
> But "alias this" is just a way to have implicit casting, and that's something (probably rightly) opposed here on principle, so I don't think we'll be having it anytime soon.

Why does this work?

void func(string a)
{
...
}

func("string literal");