Interpolated strings and SQL

[Walter Bright]

Thank you for your thoughts!

On 1/8/2024 11:30 PM, Nickolay Bukreyev wrote:> 1.  First of all, I’d like to 
notice that in the DIP1027 variant of the code we
> see:
> 
>      > `auto fmt = arg[0];`
> 
>      (`arg` is undeclared identifier here; I presume `args` was meant.)

Yes. I don't have sql on my system, so didn't try to compile it. I always make 
typos. Oof.

> There is a problem: this line is executed at CTFE,

It's executed at runtime. The code is not optimized for speed, I just wanted to 
show the concept. The speed doesn't particularly matter, because after all this 
is a call to a database which is going to be slow. Anyhow, DIP1036 also uses 
unoptimized code here.


> 3.  DIP1036 appeals more to me because it passes rich, high-level information 
> about parts of the string. With DIP1027, on the other hand, we have to extract 
> that information ourselves by parsing the string character by character. But the 
> compiler already tokenized the string; why do we have to do it again? (And no, 
> lower level doesn’t imply broader possibilities here.)

DIP1036 also builds a new format string.

>      It may have another implication: looping over characters might put current 
> CTFE engine in trouble if strings are large. Much more iterations need to be 
> executed, and more memory is consumed in the process. We certainly need numbers 
> here, but I thought it was important to at least bring attention to this point.

It happens at runtime.


> 4.  What I don’t like in both DIPs is a rather arbitrary selection of meta 
> characters: `$`, `$$` and `%s`. In regular strings, all of them are just normal 
> characters; in istrings, they gain special meaning.

I looked at several schemes, and picked `$` because it looked the nicest.

>      I suppose a cleaner way would be to use `\(...)` syntax (like in Swift). So 
> `i"a \(x) b"` interpolates `x` while `"a \(x) b"` is an immediate syntax error. 
> First, it helps to catch bugs caused by missing `i`.

I'm sorry to say, that looks like tty noise. Aesthetic appeal is very important 
design consideration for D.

> Second, the question, how 
> do we escape `$`, gets the most straightforward answer: we don’t.

It will rarely need to be escaped, but when one does need it, one needs it!


>      A downside is that parentheses will always be required with this syntax. 
> But the community preferred them anyway even with `$`.

DIP1027 does not require ( ) if it's just an identifier. That makes for the 
shortest, simplest istring syntax. The ( ) usage will be relatively rare. The 
idea is the most common cases should require the least syntactical noise.

Also, the reason I picked the SQL example is because that is the one most cited 
as being needed and in showing the power of DIP1036 and because I was told that 
DIP1027 couldn't do it :-)

The intent of DIP1027 is not to provide the most powerful, richest mechanism. 
It's meant to be the simplest I could think of, with the most attractive 
appearance, minimal runtime overhead, while handling the meat and potatoes use 
cases.