• Georg Wrede (53/63) Apr 04 2009 For some reason, nobody seemed to have read this question.
• Nick Sabalausky (7/22) Apr 04 2009 The other strange thing about it is that what a string mixin creates is ...

Georg Wrede <georg.wrede iki.fi> writes:

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...



On a related note, seems an object of a scope variable in a mixin 
doesn't get destructed. Is this a result of some hack, or intended behavior?

Below, instance "scope_mixi_a" never gets destructed.

======================================================

import std.stdio;

class Ob
{
     string myname;
     this(string s)
     {
         myname = s;
         // writeln("Ob ", myname, " created.");
     }

     ~this() {writeln("Ob ", myname, " destructed.");}
}

template mixi()
{
     scope mixi_a = new Ob("scope_mixi_a");
     auto mixi_b = new Ob("auto_mixi_b");
}

void main()
{
     scope x = new Ob("scope_x");
     auto  y = new Ob("auto_y");
     {
         scope a = new Ob("scope_a");
         auto  b = new Ob("auto_b");

         mixin mixi;

         scope c = new Ob("scope_c");
         auto  d = new Ob("auto_d");
         writeln(" -- last line of inner scope");
     }
     scope z = new Ob("scope_z");
     auto  u = new Ob("auto_u");
     writeln(" -- last line of outer scope");
}

======================================================
Output:

  -- last line of inner scope
Ob scope_c destructed.
Ob scope_a destructed.
  -- last line of outer scope
Ob scope_z destructed.
Ob scope_x destructed.
Ob auto_u destructed.
Ob auto_d destructed.
Ob auto_mixi_b destructed.
Ob auto_b destructed.
Ob auto_y destructed.

"Nick Sabalausky" <a a.a> writes:

"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:gr8a9l$grv$3 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.