opMixin or mixin function templates with convenience operator?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Thu Dec 12 19:42:59 UTC 2019
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.
More information about the Digitalmars-d