Referring to alias parameters in a mixin template

[aldanor via Digitalmars-d-learn]

On Wednesday, 17 December 2014 at 12:49:10 UTC, anonymous wrote:
> As far as I understand, the string mixin is resolved first, and
> then the template mixin takes place. So the progression is
> somewhat like this (pseudo code):
>
> ----
> mixin makeProperty!(int, "foo", f);
>
> /* Replace "makeProperty" with its definition. */
> mixin (T, name, func){mixin("T %s() @property { return
> func();}".format(name));}!(int, "foo", f);
>
> /* First round, substitute arguments for parameters. `T` and
> `func` are not replaced, because they're just string contents at
> this point. */
> mixin (T, name, func){mixin("T %s() @property { return
> func();}".format("foo"));}!(int, "foo", f);
>
> /* Evaluate `format` and do the string mixin. */
> mixin (T, name, func){T foo() @property { return func();}}!(int,
> "foo", f);
>
> /* Second round, substitute arguments for parameters. This time,
> `T` and `func` are replaced. */
> mixin (T, name, func){int foo() @property { return f();}}!(int,
> "foo", f);
>
> /* Didn't do any string mixins in the second round, so there's 
> no
> need for a third round. Get rid of template parameters and
> arguments. */
> mixin {int foo() @property { return f();}};
>
> /* Finally, do the template mixin. */
> int foo() @property { return f();}
> ----
>
> Not sure if that helps or maybe it just adds to the confusion.
>
> As to if there were `T` or `func` in the target scope, they'd be
> shadowed by the template parameters, no matter if there's a
> string mixin or not.
That makes sense. So if I understand correctly, basically after 
each string mixin it has to check if any new symbols were leaked 
into the current scope and then try to resolve them, if any, with 
template parameters taking precedence over local variables? (This 
obviously has to repeat in case of nested mixins)

Thanks again!