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.

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?

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

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.

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?

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.

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.

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");