digitalmars.D - Mixin mystic

That explains a certain mystery I encountered in a library I wrote.
Everything *seemed* like it should have worked with "scope" instead
of "auto" but it never did. The variables that were mysteriously
unconvertable to "scope" were declared in a mixin.
This makes me wonder though: should mixins be implicitly creating a
new scope at all? Clearly there are cases where it's desireable to not
have that implicit scope, and with the current behavior I don't see a
workaround. Are there cases where an implicit new scope would be
desired? If so, could those cases be sufficiently worked around by
explicitly creating a new scope in the mixin?

That explains a certain mystery I encountered in a library I wrote.
Everything *seemed* like it should have worked with "scope" instead
of "auto" but it never did. The variables that were mysteriously
unconvertable to "scope" were declared in a mixin.
This makes me wonder though: should mixins be implicitly creating a
new scope at all? Clearly there are cases where it's desireable to not
have that implicit scope, and with the current behavior I don't see a
workaround. Are there cases where an implicit new scope would be
desired? If so, could those cases be sufficiently worked around by
explicitly creating a new scope in the mixin?

For some reason, nobody seemed to have read this question.
One would think that the mixin not creating a new scope would be what the
programmer expects. Or at least hopes...

The other strange thing about it is that what a string mixin creates is not
so much an implicit scope as it is an implicit "semi-scope". Ie, if you
declare a non-scope variable in a string mixin, it'll outlive the mixin
(which is good, string mixings would be far less useful otherwise), but with
a normal manual scope that would not be the case.