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.

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.

Now on reddit:
http://www.reddit.com/r/programming/comments/7j7gc/lock_options_a_compiletime_deadlock_prevention/

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.

"Frits van Bommel" <fvbommel@REMwOVExCAPSs.nl> wrote in message news:gi06f7$274a$1@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?