i"$foo $bar" makes a string literal at the call site, no one gets to format anything, make templates, or anything else; no change to templates syntax for to match some strange usecase that no one remembers anymore.

i"$$"=='$' double $ is the excape, so theres only one control char that changes

float f=1.337; assert(i"$f"=="1.34"); floats are round two digits, always

Vector2 v; assert(i"$v"==v.toString); structs reuse the toString norms

int array=[1,2,3]; assert(mixin(i"$array")==array); base types and combinations of base types, create sane mixins

On Sunday, 14 January 2024 at 23:20:36 UTC, monkyyy wrote:

what about security issues such as sql injection?

On Monday, 15 January 2024 at 00:11:13 UTC, Alexandru Ermicioi wrote:

sounds like an awful lot of sql's problem, and what do you want the compiler to throw an exception?

what if someone else wants a string that doesn't throw an exception based on some software that they may not even be aware of?

On Monday, 15 January 2024 at 00:11:13 UTC, Alexandru Ermicioi wrote:
and combinations of base types, create sane mixins

Have the other languages solved security issues in their string interpolation?

https://www.geeksforgeeks.org/python-string-interpolation/

On Monday, 15 January 2024 at 00:11:13 UTC, Alexandru Ermicioi wrote:

If your programmer is using string interpolation for sensitive sql queries, you fire the programmer.

On Thursday, 18 January 2024 at 20:30:43 UTC, cc wrote:

You will, but first, you'd get your company software breached, so perhaps it is best to not allow such things in first place (language).

On Thursday, 18 January 2024 at 23:05:03 UTC, Alexandru Ermicioi wrote:

Then it might be best not to allow any such practice of injecting dynamic string data into a constructed string command that will be fed into an interpreter that doesn't discriminate between querying and manipulating data in the first place. To echo another poster, that's SQL's problem.😉

Nothing wrong with saying "let's make this system a little better", but how far is a language really obligated to go to protect users from doing the same terrible thing they do in every other language with a database interface known to have some of the widest attack surfaces in history? Not a rhetorical question: I can see some advantage to D being able to say "hey look, our string interpolation is THIS good, you can do this with it and not get screwed!", but I can also see it going too far and creating a wasteland of "can't have nice things" because someone somewhere will carry on the same old bad practices of shooting themselves in both feet with it.

Just my irrelevant 2 cents, anyway. That ship has sailed, but worth remembering for the next one to come into port, IMO.

On Friday, 19 January 2024 at 10:07:38 UTC, cc wrote:

That is actually a problem for html templates as well, and any use case where a string template is desired to be used.

Sloppy job is also a problem, and that is not related much to experience.

Can't wait to try out dip1036e in reference compiler :). I guess we can stop this thread at this point of time.

Regards,
Alexandru.

On Thursday, 18 January 2024 at 23:05:03 UTC, Alexandru Ermicioi wrote:

You mean the current way

query("select * from student where name='"~bobby~"'");

is ugly enough that nobody will use it accidentally?

I dont understand, why string interpolation related to sql injection at D forums.
IMHO, this is parallel things.
SQL injection problem should be (IMHO) solved by using "prepare statement" phase.
Programmer call sql.prepare().
DB driver make one call to DB server to send query with placeholders.
DB server prepare query to execute.

Then programmer call sql.bind_parameters() or sql.execute_with_parameters().
DB driver make another, separated call to DB server with parameters values and its types.

If parameter contains injection - it will not works.
Server not concatenate parameter with query.
Prepares query on DB server can be as parsed AST tree, not query string.

IMHO, string interpolation should no be used for DB code.