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.

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