On 10/25/2023 4:29 AM, Jonathan M Davis wrote:
> IMHO, mixins should be explicit, obvious, and greppable, and adding a
> separate syntax for them which tries to hide them is going to make the
> language worse. However a string is generated, if the programmer wants to
> turn it into code, they should just use mixin, and if it's ugly, it's ugly,
> but at least it's clear what's going on.

Yes, that was and remains the rationale for mixin. We have plenty of experience with it now, and it's been good.

Trying to hide this stuff away is also what macros do, and every language that supports macros winds up with hellish incomprehensible code (that the authors of such insist is beautiful!).

And lastly, the discomfort with this seems to be related to discomfort with tuples. D doesn't support tuples as well as it should, which results in people not using tuples where tuples are appropriate, and hence unfamiliarity with them.

D is going to get better tuple support (like having functions able to return tuples), and when we do, I expect using tuples will become natural for D programming.

On Wednesday, 25 October 2023 at 20:07:32 UTC, bachmeier wrote:
> On Wednesday, 25 October 2023 at 19:15:42 UTC, duckchess wrote:
>
>> ```d
>> writeln(i!"${foo++}"); // error, cant mutate foo. need to use explicit mixin(i!"${foo++}")
>> ```
>
> If someone wants to do this, they clearly don't understand the purpose of string interpolation. Code like that should be reserved for the C preprocessor.

This is what I'd call a "job retaining" code! =]

Matheus.

PS: Remembering WB presentation this year at DConf, I'd like to know if this is case do go to his office or not.

On 10/25/2023 12:09 PM, Adam D Ruppe wrote:
> And newer additions to languages try to do it right:
> 
> https://openjdk.org/jeps/430

The money shot:

"The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program."

On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:
> The money shot:
>
> "The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program."

Yup. Even if we went with an object in D instead of a tuple, I'd be against the `alias toString this;` part. Just too much history saying that's a bad idea for D to embrace it at this point.

On Wednesday, October 25, 2023 7:47:33 PM MDT Adam D Ruppe via Digitalmars-d wrote:
> On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:
> > The money shot:
> >
> > "The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program."
>
> Yup. Even if we went with an object in D instead of a tuple, I'd be against the `alias toString this;` part. Just too much history saying that's a bad idea for D to embrace it at this point.

Implicit conversions are fraught with dangers in general. Sometimes, they're really useful to have, but they're often problematic, and they're even more problematic in generic code. So, they should be used with care, and IMHO, we should default to avoiding them rather than adding them.

- Jonathan M Davis

On Thursday, 26 October 2023 at 02:02:49 UTC, Jonathan M Davis wrote:
> On Wednesday, October 25, 2023 7:47:33 PM MDT Adam D Ruppe via Digitalmars-d wrote:
>> On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:
>> > The money shot:
>> >
>> > "The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program."
>>
>> Yup. Even if we went with an object in D instead of a tuple, I'd be against the `alias toString this;` part. Just too much history saying that's a bad idea for D to embrace it at this point.
>
> Implicit conversions are fraught with dangers in general. Sometimes, they're really useful to have, but they're often problematic, and they're even more problematic in generic code. So, they should be used with care, and IMHO, we should default to avoiding them rather than adding them.
>
> - Jonathan M Davis

I'm just putting it here as an observation.

If D does not provide a way to implicitly get a string, it would be the *only* language that would do so.

All other languages with more than 10 users has a way to do that.

I even asked GPT-4 etc and it could not provide any examples of a language where you can't easily get a string from the expression or where it's the default.

As more or less the collective knowledge of humanity, maybe we should listen to it.

If we don't, it's more likely that we are wrong, not everyone else.

On 26/10/23 3:47, Adam D Ruppe wrote:
> On Thursday, 26 October 2023 at 00:24:33 UTC, Walter Bright wrote:
>> The money shot:
>>
>> "The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program."
> 
> Yup. Even if we went with an object in D instead of a tuple, I'd be against the `alias toString this;` part. Just too much history saying that's a bad idea for D to embrace it at this point.

You are not mentioning this part:

> The template expression STR."..." is a shortcut for invoking the process method of the STR template processor. That is, the now-familiar example:
> 
> String name = "Joan";
> String info = STR."My name is \{name}";
> 
> is equivalent to:
> 
> String name = "Joan";
> StringTemplate st = RAW."My name is \{name}";
> String info = STR.process(st);
> 
> where RAW is a standard template processor that produces an unprocessed StringTemplate object.

I would find it perfect if there were an option to define arbitrary prefixes to strings (other than the ones already used by the language), like `i"Hello, ${name}` or `sql"SELECT * FROM ${table};"`. Notice how the string itself doesn't need any marker in Java:

> String name = "Joan";
> String info = "My name is \{name}";
> | error: processor missing from template expression

It's needing both what I don't like and find confusing: `string s = i"Hello, ${world}".format` (or `.text`).

We can do like Java, and assume that as soon as a template expression is found, it will be automatically considered an interpolated string, so actually strings literals will be interpolated by default, and only if there are no expressions the result would be a `string`.