opMixin or mixin function templates with convenience operator?

[Ola Fosheim Grøstad]

On Thursday, 12 December 2019 at 19:08:40 UTC, Paul Backus wrote:
> I don't think it's any harder to use than the `mixin` keyword, 
> though I'll concede that it's more cryptic to read and harder 
> to search for in the documentation.

I think a solution for string interpolation has to be very close 
to what other languages offer, maybe it would have to be made a 
special case for strings.

> On the other hand, I think both of those arguments also apply 
> to opMixin. Newbies are not likely to have an easy time 
> understanding the difference between `foo!(args)` and 
> `foo#(args)`. (After all, they already get tripped up by the 
> difference between `foo(args)` and `foo!(args)`.)

Yes, I agree.

If you specialcase mixin-providers that only take one string 
parameter, then it is possible to come up with a protocol, that 
can provide something that is "fool proof" and simple syntax:

    f#"..."       $f"..."      f«...»     f!!"…"       f"""…"""

The compiler type checks the variable f for satisfying a 
string-interpolation protocol. And it is only allowed to return a 
mixin string that generates a pure lambda function with const 
parameters and some other constraints. Could even constrain the 
lambda to return a string or tuple.

> Are you proposing a language-level distinction between "string 
> that contains D code for mixing in" and "string that contains 
> some other kind of data"?

Yes, I guess it would be possible to type a mixin-string in such 
a way that it is only allowed to represent a lambda function that 
is being called. As in typing the string to a function signature, 
would be one step.

Maybe it can be expressed in D code already.

Probably not enough, but one step.