December 09, 2021

On Thursday, 9 December 2021 at 15:20:42 UTC, WebFreak001 wrote:

>

I don't think the common case should always have this extra i prefix + needed function calling parentheses or ufcs dot. Just only writing text"hello $name" is shorter, easier to type, better to read.

Yes, in my experience I primarily use string interpolation when the API does not allow a comma-separated list. For instance if you throw an exception and there only is a message parameter.

I guess one could say that string interpolation shines where it overcomes API limitations, but it has to be concise.

December 09, 2021

On 12/9/21 10:20 AM, WebFreak001 wrote:

>

On Thursday, 9 December 2021 at 15:16:40 UTC, WebFreak001 wrote:

>

On Thursday, 9 December 2021 at 14:57:25 UTC, Steven Schveighoffer wrote:

>

[...]

i.e. this is practically identical to:

sql(i"SELECT x,y,z FROM $something WHERE $condition");

Or even:

i"SELECT x,y,z FROM $something WHERE $condition".sql;

[...]

and I want to add, this is the super rare case:

foo(i"hello $name")

I disagree. I find that the non-rare case. This is what I'm looking for. The interesting case is not some specialized function that transforms the parameters into a string in a specific way, but one that accepts the parameters as-is and works with them directly.

>

this is the much more common case:

foo(i"hello $name".text)
// or
foo(text(i"hello $name"))

In my original DIP, I tried to handle both cases, foo(i"hello $name") for foo(string) would work. It's a messy situation, and I think it's the reason there was so much opposition.

Having to type text or whatever is a reasonable compromise.

>

I don't think the common case should always have this extra i prefix + needed function calling parentheses or ufcs dot. Just only writing text"hello $name" is shorter, easier to type, better to read.

Note that the string interpolation proposal does not preclude this possibility happening later.

Reasonable people can disagree whether this "makes the feature" or not though.

-Steve

December 09, 2021

On Thursday, 9 December 2021 at 15:47:11 UTC, Steven Schveighoffer wrote:

>

On 12/9/21 10:20 AM, WebFreak001 wrote:

>

I don't think the common case should always have this extra i prefix + needed function calling parentheses or ufcs dot. Just only writing text"hello $name" is shorter, easier to type, better to read.

Note that the string interpolation proposal does not preclude this possibility happening later.

You can fix this with implicit conversion to string, but it makes for weaker typing:

  1. expand to list

  2. if expanding to list fails type check then try to concatenate to string

  3. if string does not pass type check, report error

So, it is easy to fix without any extra .text annoyances.

December 09, 2021
On Thursday, 9 December 2021 at 15:55:42 UTC, Ola Fosheim Grøstad wrote:
> You can fix this with implicit conversion to string, but it makes for weaker typing:

This has been discussed over many years.

If you haven't read the previous DIPs and those too, you aren't contributing anything. It is a complete waste of time to go over this over and over and over and over and over and over again.
December 09, 2021
On Thursday, 9 December 2021 at 12:43:31 UTC, Adam D Ruppe wrote:
> On Thursday, 9 December 2021 at 10:43:07 UTC, deadalnix wrote:
>> So I read the proposal for string interpolation in D, which I understand to be this one: https://github.com/John-Colvin/YAIDIP
>>
>> The immediate thing that stroke me is the shell example. The proposed exemple is simply terrible code as it allows for shell injection.
>
> You say you read it, then say something that is blatantly false about it.
>
> This dip does NOT produce strings. It produces argument lists. The receiving function knows what was part of the string literal and what were arguments and can process them accordingly.

I see. I misunderstood that part, so scratch that.

It's not as bad as I thought, but it definitively feel hacky. It is unclear to me this is worth the complexity.
December 09, 2021

On Thursday, 9 December 2021 at 14:04:18 UTC, Kagamin wrote:

>

On Thursday, 9 December 2021 at 13:27:06 UTC, Ola Fosheim Grøstad wrote:

>

A bit clunky. With a custom interpolation function you could overload on the return type and have domain specific syntax.

DSLs are already possible with template mixins in a clean form without sigils.

No, there are identifier resolution problems.

It's like we don't want macro, so we reinvent 20 bad versions of them in the effort of not implementing them.

December 09, 2021
On Thursday, 9 December 2021 at 13:24:14 UTC, Adam D Ruppe wrote:
> On Thursday, 9 December 2021 at 13:03:21 UTC, Ola Fosheim Grøstad wrote:
>> But don't you think it would be better if you could write:
>
> No.

Ola's direction does compose much better.
December 09, 2021

On Thursday, 9 December 2021 at 14:18:35 UTC, Steven Schveighoffer wrote:

>

No, it doesn't. This tells me you are missing something in your understanding of the proposal.

-Steve

You are correct, apologies.

December 09, 2021

On Thursday, 9 December 2021 at 14:25:58 UTC, WebFreak001 wrote:

> >

But don't you think it would be better if you could write:

sql"SELECT x,y,z FROM {something} FROM {condition}"

[...]

Love the idea of having type-safety with this! JS has similar syntax with sql`...` where it will call the function sql with the parts of the interpolated string.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

This approach has proven extremely useful in many contexts. I'm not sure why this is frowned upon.

December 09, 2021

On Thursday, 9 December 2021 at 16:02:19 UTC, Adam D Ruppe wrote:

>

On Thursday, 9 December 2021 at 15:55:42 UTC, Ola Fosheim Grøstad wrote:

>

You can fix this with implicit conversion to string, but it makes for weaker typing:

This has been discussed over many years.

If you haven't read the previous DIPs and those too,

I read the current DIP, I read some of the other DIPs a long time ago, no need to feel offended.

I would not recommend weaker typing, as it would be trivial to get stronger typing by simply supporting f"this $will become a string" and i"this $will become a list".

But if one is hellbent on having the DIP as stated you end up with something that is very unfriendly to newbies.

It does not make the language more accessible. As enthusiasts you need to think a little bit further than your own perception of "good".