Lock Options in D article in Dr. Dobb's

[Nick Sabalausky]

"Frits van Bommel" <fvbommel at REMwOVExCAPSs.nl> wrote in message 
news:gi06f7$274a$1 at digitalmars.com...
> Walter Bright wrote:
>> Bartosz Milewski has just published "Lock Options" in the January Dr. 
>> Dobb's.
>>
>> http://www.ddj.com/cpp/212201754
>>
>> He provides a D implementation of it.
>
> Unfortunately, I'm pretty sure it's buggy :(.
> In his final implementation he uses a mixin to create a declaration for a 
> scope variable (the lock).
> That variable will be destroyed before the end of the mixin, not before 
> the end of the containing scope (statement mixins create an implicit 
> scope).
>
> See for yourself:
> -----
> module test;
>
> import tango.io.Console;
>
> class Verbose {
>     this() { Cout("Constructed").newline(); }
>     ~this() { Cout("Destructed").newline(); }
> }
>
> void main() {
>     Cout("Start of main").newline();
>     mixin("scope lock = new Verbose;");
>     Cout("End of main").newline();
> }
> -----
> Output:
> =====
> Start of main
> Constructed
> Destructed
> End of main
> =====
>
> It should work without that mixin, but it won't be nearly as nice-looking.

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?