On Thursday, 9 December 2021 at 16:24:12 UTC, deadalnix wrote:
>> 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.

This approach is virtually identical to the dip in substance. The only difference is in syntax.

In Javascript, it is a magic function call syntax. The D proposal is to use standard function call syntax, which fits D better since we have two kinds of "function calls" - template arguments and run-time arguments. Reusing existing syntax lets us use this in both cases without any special rules.

But both pass similar data and have similar results.

The Javascript approach is good evidence that this separation of data and strings is desirable and useful.

On Thursday, 9 December 2021 at 16:30:28 UTC, Ola Fosheim Grøstad wrote:
> I would not recommend weaker typing, as it would be trivial to get stronger typing

This is factually false.

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

Your objection has been noted and overruled. Good bye.

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

Ola may be ignorant of the previous DIP, I do not know. I certainly am.

However, I have migration multi million LOC codebase toward safer string interpolations constructs that catched real bugs and hardened security.

The kind of solution used then resemble much more what Ola describes than what the current proposal describes.

The proposed solution has serious drawbacks compared to more standard approaches, to begin with, such as not behaving like an expression and requiring the consumer to be aware of the construct.

On Friday, 10 December 2021 at 01:00:57 UTC, Steven Schveighoffer wrote:
>
> Which comma? there are commas in the string too. You have to parse the string first to find the right comma.
>

The first comma after the string. I don't even think. My brain takes me straight there, automatically (seemingly without parsing the string).

Whatever thinking my brain does, it is not apparent to me ;-)

>
> So you just ignore the string? What if there are parameter mismatches?
>
> -Steve

That's an extra task to be undertaken, if needed.

e.g. say you have to change one or more of your parameter names (but don't need to change their order). Well, it's much easier NOT to be forced to parse an entire interpolated string.

There are pro's and con's, I accept that. But having done without interpolated strings, for decades, I don't see the point of introducing them, and then having to deal with TWO different ways to achieve the exact same outcome.

On Friday, 10 December 2021 at 02:32:32 UTC, Steven Schveighoffer wrote:
>
> I guess then it comes down to which brain you have. My brain does not see the immediate correlation between disjoint string placeholders and parameter values. I have to look back and forth, especially with long SQL statements, counting question marks (often times some values are in the SQL string and not parameters).
>
> To each his own, and fortunately, we can have both ways!
>
> -Steve

but if there were only one way, it would not matter which brain we had, as it would be doing exactly the same thing.

with both ways, it's even worse, as your brain, and mine, now need to know how to do both.

In the end, what is really achieved? -> Just added complexity.