String interpolation, after a healthy debate on discord

[WebFreak001]

On Tuesday, 14 December 2021 at 14:01:56 UTC, rikki cattermole 
wrote:
>
> On 10/12/2021 10:06 AM, WebFreak001 wrote:
>> What do you think? Would this be essential for interpolated 
>> string adoption in user code or be useless?
>
> I am against it.
>
> Due to it marrying a memory management+formatting strategy to 
> the language.
>
> One way to do this is to support ``Identifier Token`` UFCS 
> pattern which would allow this to "just work" except 
> generically.

what do you mean with this? Memory management isn't part of the 
language or the proposal here (you need to use std.conv : `text`) 
and the syntax you propose here is the exact syntax proposed in 
the post. I don't quite get where you disagree or why you are 
against it from this paragraph at least.

> So if you want to get data from your database?
>
>     auto data = dbcon.sql`SELECT * FROM table where field = 
> "%value$arg"`;
>
> That could pass it in as an interpolated string.
>
> However, that could be extremely confusing to the user as this 
> is a function call, which takes a string... yet its actually 
> something very different. Like why doesn't adding the brackets 
> allow for that to work? ext. ext.

this is the same as JS template literal syntax - it's another way 
of calling a function. Given how different it looks from regular 
function calls, I don't think you would be very confused. The 
compiler would also tell you that you are trying to pass a string 
to a function that checks for an istring.

Just like currently `a.ufcsFun(b)` works but `&a.ufcsFun` to take 
its address doesn't, even though `a.memberFun(b)` works and 
`&a.memberFun` takes its address - I don't think anyone is 
confused about it, or at least it's easy to learn why the UFCS 
one doesn't work, just as it will with this proposal.

> One reason I would like this pattern even though I don't think 
> we should ever have it is so that I can have hex strings back. 
> Super useful during code generation and table generation for 
> large data sets (now days I've found that std.base64 does an 
> excellent job at this, even with a little bit of fluff).
>
> ubyte[] data = hex"AABBCC"; // ok

I was thinking about this as well - it would work but would run 
at runtime. I'm not a fan of using it just for static data and 
think `hexString!"..."` is better for that.