We are forking D

[Walter Bright]

On 1/7/2024 1:22 AM, Paolo Invernizzi wrote:
> The whole point is, well, let's move on and simplify it!

Of course!


> DIP1036 could allow us to do that, with better library code and more 
> encapsulation, your proposal simply can't do that without what you call 'more 
> burden'.

I asked the question if adding a template call constituted an "undue" burden. 
What it does do is send a clear visual signal that the default behavior of 
istring is being adjusted.

> Long story short: in our codebase, we will stick with mixins with your proposal 
> merged, on the contrary, we will use DIP1036 functionalities if merged.

Using DIP1036 for string interpolation means that for using it for sql calls means:

1. if something other than core.interpolation is imported at the global level, 
it will apply to all users of istring in that module, not just the ones calling 
sql functions. It means calling writeln with istrings won't do what is expected, 
and this is not visually apparent by looking at the code, nor is it checkable by 
the compiler.

2. an alternative would be locally importing core.interpolation or arsd.sqlite 
as required for each scoped use of istrings.