"Georg Wrede" <georg.wr...@iki.fi> wrote in message news:gr8a9l$gr...@digitalmars.com... > On December 14, Nick Sabalausky wrote: > > 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.