We are forking D

[brianush1]

On Sunday, 7 January 2024 at 18:51:40 UTC, Walter Bright wrote:
> 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.

It seems you have a fundamental misunderstanding of what DIP1036 
is, so here's a quick explanation: `i"$​(str) has $​(num) 
items."` becomes


     AliasSeq!(
         InterpolationHeader(),
         InterpolatedExpression!"str",
         str,
         InterpolatedLiteral!" has ",
         InterpolatedExpression!"num",
         num,
         InterpolatedLiteral!" items.";
         InterpolationFooter(),
     )


`InterpolationHeader`, `InterpolatedExpression`, 
`InterpolatedLiteral`, and `InterpolationFooter` are defined in 
core.interpolation, which doesn't need to be imported in order to 
use interpolated strings.

Not arsd.sqlite, nor any other library, defines their own 
interpolated strings. Importing a library does not and cannot 
change the behavior of interpolated strings, that is a 
misunderstanding. Library functions simple take in the 
interpolated string using a vararg template and do literally 
*whatever they want with it,* since they're given all the 
information about the interpolated string, including the 
evaluated expressions that were inside the string.