December 09, 2021

On Wednesday, 8 December 2021 at 22:10:32 UTC, Steven Schveighoffer wrote:

> conn.exec(i"UPDATE organization SET loc_lat = $loc_latitude, loc_lon = $loc_longitude WHERE id = $id");

I like it.

December 09, 2021

On Wednesday, 8 December 2021 at 22:10:32 UTC, Steven Schveighoffer wrote:

>

On 12/8/21 4:31 PM, kdevel wrote:

>

[...]

Both are readable, though I'd argue that for this particular example, the usage of $(expr) for syntax makes things complex to read (syntax highlighting should help). In our DIP we used ${expr}, which for SQL would be more readable, but might look worse for things like code mixins.

But there are plenty of examples where the string-blueprint form is less readable (the INSERT form where you specify fields first, and then parameters later is kind of a terrible syntax to begin with).

e.g. (from a real line of code in my codebase):

conn.exec("UPDATE organization SET loc_lat = ?, loc_lon = ? WHERE id = ?", loc_latitude, loc_longitude, id);

// compare to:
conn.exec(i"UPDATE organization SET loc_lat = $loc_latitude, loc_lon = $loc_longitude WHERE id = $id");

-Steve

I wonder why are most languages using $ or {}? What's the advantage over \(...)?

With \ we have the advantage of not reserving another special character in strings - we already use \! It'd be fully backwards compatible even without the i prefix.

Swift does this too.

December 09, 2021

On Thursday, 9 December 2021 at 07:47:40 UTC, WebFreak001 wrote:

>

On Wednesday, 8 December 2021 at 22:10:32 UTC, Steven Schveighoffer wrote:

>

On 12/8/21 4:31 PM, kdevel wrote:

>

[...]

Both are readable, though I'd argue that for this particular example, the usage of $(expr) for syntax makes things complex to read (syntax highlighting should help). In our DIP we used ${expr}, which for SQL would be more readable, but might look worse for things like code mixins.

But there are plenty of examples where the string-blueprint form is less readable (the INSERT form where you specify fields first, and then parameters later is kind of a terrible syntax to begin with).

e.g. (from a real line of code in my codebase):

conn.exec("UPDATE organization SET loc_lat = ?, loc_lon = ? WHERE id = ?", loc_latitude, loc_longitude, id);

// compare to:
conn.exec(i"UPDATE organization SET loc_lat = $loc_latitude, loc_lon = $loc_longitude WHERE id = $id");

-Steve

I wonder why are most languages using $ or {}? What's the advantage over \(...)?

With \ we have the advantage of not reserving another special character in strings - we already use \! It'd be fully backwards compatible even without the i prefix.

Swift does this too.

I think it's because the idea for interpolated strings evolved from template engines / perl's variable interpolation (which sort of is string interpolation) where syntaxes for values etc. are commonly using {x} {{x}} $x etc.

So it's probably just to keep it similar to that, as those are familiar syntaxes and has been through decades.

Doesn't mean it's the best or can't be improved, but sometimes introducing new syntaxes etc. also introduces new complexities and additional learning curve.

December 09, 2021

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

>

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#compilation-of-interpolated-strings

>

Beginning with C# 10, when an interpolated string is used, the compiler checks if the interpolated string is assigned to a type that satisfies the interpolated string handler pattern

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.

Disclaimer: I have not watched the what C# did before writing this.

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.

One of the motivating example is SQL prepared statements, but once again, replacing this by the proposed string interpolation means SQL injection.

In its current form, I'm not convinced the current proposal is something we want. If this reaches any kind of scale, this will inevitably end up as a forbidden language construct in a linter.

December 09, 2021

On Thursday, 9 December 2021 at 07:47:40 UTC, WebFreak001 wrote:

>

I wonder why are most languages using $ or {}? What's the advantage over \(...)?

$ is a historical variable prefix, dates back to BASIC and shell scripting languages, so basically back to the 60s and 70s. It makes variable-substitution stand out visually.

{} is really the best "mnemonic" as it signifies a chunk of executed code, so from a usability perspective that is the best option. Then you can use {{ for escape. People who love string mixins probably disagree…

I don't like backslashes for common escapes, makes code harder to read. Anyone that has spent a significant amount of time debugging long regex's can attest to that. The backslash is used for so many other escapes in strings and custom string notations that it does not stand out as much.

December 09, 2021

On Thursday, 9 December 2021 at 10:43:07 UTC, deadalnix wrote:

>

In its current form, I'm not convinced the current proposal is something we want. If this reaches any kind of scale, this will inevitably end up as a forbidden language construct in a linter.

What I don't understand is why meta-programming isn't strengthened instead so that string interpolation can be implemented as a library construct. If you then put it in the standard library compilers can recognize it and optimize for it.

You basically need:

  1. custom literals (seek inspiration in C++)
  2. some limited AST rewriting capabilities.

That would also make it much easier to write DSLs.

D needs to hunker down on meta-programming and not spread itself thin across the feature-set of other languages.

There is also no universal syntax for interpolation that works in all contexts. E.g. in regexes many symbols will be confusing, in complicated strings with many sigils you want substitution to stand out (which is why Angular uses {{…}}). In a DSL you can also have much safer and more convenient interpolation, e.g. a SQL DSL could check that tables exists in a model at compile time or something to that effect. Bring custom verification of string-literals by adding user defined literals instead.

D really needs to stop running after other languages and instead bring unique benefits to programmers, based on meta-programming.

December 09, 2021

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

December 09, 2021
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.
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.

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

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

Then have a user provided custom compile time function check the string and wrap something and condition with the proper escape-functions. Then you could pass it anywhere you want as a properly typed SqlStatement. All you need is something like:

SqlStatement string_interpolation(string!"sql" s){
…
}

Which is called when a sql"…" literal fails to convert, that allows libraries to override the default string_interpolation.

You could let string!"sql" be a subtype of string for ease of use.

Just one possibility that is much more flexible and safer as it actually is typed. D should aim for generic programming within the current framework, not add new weird special cases (tuples are bad enough, no need to have more of that).

December 09, 2021

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

>

Which is called when a sql"…" literal fails to convert, that allows libraries to override the default string_interpolation.

Didn't mean convert, meant bind to parameters. E.g.

void myfunc(string!"sql" s) would take precedence over string_interpolate.