December 10, 2021

On Thursday, 9 December 2021 at 14:30:33 UTC, Ola Fosheim Grøstad wrote:

>

I am not suggesting the implementation of builtin string interpolation, but custom literals with conversion functions. It should probably not be called string_interpolation, just convert or @convert.

This is different from string mixins as it would be more composable, overloadable, and with stronger typing and no mixin.

I looks like you propose string mixin with a different syntax. If behavior is customizable, you can't guarantee the custom handler will use a strong type system and provide all those features you want.

December 10, 2021

On Friday, 10 December 2021 at 08:26:38 UTC, Kagamin wrote:

>

I looks like you propose string mixin with a different syntax. If behavior is customizable, you can't guarantee the custom handler will use a strong type system and provide all those features you want.

Not sure what you mean by guarantee, it will enable stronger typing than the DIP for sure.

If you want to force strong typing (not sure why) then you require a grammar to be associated with the string tag. This would also enable automatic string validation, auto completion in IDEs etc.

December 10, 2021
On 12/9/2021 2:43 AM, 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

This is the one I proposed:

https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1027.md

which is simple and straightforward.
December 10, 2021

On Thursday, 9 December 2021 at 16:16:58 UTC, deadalnix wrote:

>

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.

That's what L stands for in DSL. As opposed to interpolated string, DSL has semantics, which can inform identifier resolution.

December 10, 2021

On Thursday, 9 December 2021 at 12:21:06 UTC, Kagamin wrote:

>

On Wednesday, 8 December 2021 at 10:46:31 UTC, WebFreak001 wrote:

>

Usage example: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/interpolated-string-handler

What do you think of these extended interpolated string expressions? I think these would fit well into D, and could give some new motivation now that we have had our interpolated strings DIPs rejected once and withdrawn once.

Not sure if this is much better than FormattableString overloads: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#implicit-conversions-and-how-to-specify-iformatprovider-implementation

The interpolated handler can skip some expressions in the interpolated string or can use more performant inner details like spans. FormattableString parses all arguments and format them.

December 12, 2021

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 by simply supporting f"this $will become a string" and i"this $will become a list".

That would have the problem that confusing i"" and f"" could lead to SQL injections and related problems. The improvement over using i"".text is almost nonexistent.

December 12, 2021

On Sunday, 12 December 2021 at 19:44:17 UTC, Q. Schroll wrote:

>

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 by simply supporting f"this $will become a string" and i"this $will become a list".

That would have the problem that confusing i"" and f"" could lead to SQL injections and related problems. The improvement over using i"".text is almost nonexistent.

How could you confuse them? The type system would prevent it.

December 13, 2021

On Sunday, 12 December 2021 at 20:55:49 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 12 December 2021 at 19:44:17 UTC, Q. Schroll wrote:

>

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 by simply supporting f"this $will become a string" and i"this $will become a list".

That would have the problem that confusing i"" and f"" could lead to SQL injections and related problems. The improvement over using i"".text is almost nonexistent.

How could you confuse them?

In cases like this, for example?

void func(string str);
void func(Is...)(Is interpString)
  if (isInterpString!Is);

string value = "bla";
func(f"some $bla bla"); // calls first one
func(i"some $bla bla"); // calls second one

If I understand your suggestion correctly, both would compile, but be handled differently. It's a one-keystroke difference and people will conflate i"" and f"" for sure and it could lead to serious vulnerabilities. Carefully crafted func can make one an error, but not so carefully made ones might not. It becomes a hard(er)-to-use-correctly issue.

>

The type system would prevent it.

Only if it is assisted by the programmer. If the type system could distinguish all the cases, i.e. there is no case where f"" and i"" work both, you wouldn't need the distinction in the first place. One could do a best effort approach, but I agree that weak typing is bad.

December 13, 2021

On Monday, 13 December 2021 at 15:42:43 UTC, Q. Schroll wrote:

>

If I understand your suggestion correctly, both would compile, but be handled differently. It's a one-keystroke difference and people will conflate i"" and f"" for sure and it could lead to serious vulnerabilities. Carefully crafted func can make one an error, but not so carefully made ones might not. It becomes a hard(er)-to-use-correctly issue.

I don't think api's should take the interpolated-list at all. That would be a sign of a weakly typed api.

I would prefer something like sql"…", css"…" etc.

>

the first place. One could do a best effort approach, but I agree that weak typing is bad.

It is bad, yes. C is borderline untyped in some cases.

December 13, 2021
On Monday, 13 December 2021 at 16:40:31 UTC, Ola Fosheim Grøstad wrote:
> I would prefer something like ```sql"…"```, ```css"…"``` etc.

How would you implement those?