Re: emplace, scope, enforce [Was: Re: Manual...]

[Andrei Alexandrescu]

Dmitry Olshansky wrote:

On 21.07.2010 16:26, bearophile wrote:

Dmitry Olshansky:

The problem is designing such classes and then documenting: "you should
always use it as 'scope' ", is awkward.

If you really want a class to be used as scope only you can do this, see the error message:

scope class Foo {}
void main() {
   Foo f = new Foo;
}

The second writefln prints garbage. I guess it's because of pointer to
the long gone stackframe, which is ovewritten by the first writeln.

Yes scope has this and other problems (and I think two of them can be fixed), but I don't think emplace() is a big improvement.

Bye,
bearophile

Going further with library implementation as opposed to language feature, I made a (somewhat) successful try at implementing scoped classes:

I salute this approach.

struct Scoped(T){
    ubyte[__traits(classInstanceSize, Test)] _payload;

s/Test/T/ I suppose.

    T getPayload(){
        return cast(T)(_payload.ptr);
    }
    alias getPayload this;

static Scoped opCall(Args...)(Args args) if ( is(typeof(T.init.__ctor(args))) ){// TODO: should also provide decent error message

        Scoped!T s;
        emplace!T(cast(void[])s._payload,args);
        return s;
    }
    ~this(){
        clear(getPayload);
    }
}

now replace the orignal while loop with this:
while (i < N) {
        auto testObject = Scoped!Test(i, i, i, i, i, i);

//assuming we have aforementioned evil function func(Test t), that keeps global reference to t. //fun(testObject); //uncoment to get an compile error - type mismatch

        testObject.doSomething(i, i, i, i, i, i);
        testObject.doSomething(i, i, i, i, i, i);
        testObject.doSomething(i, i, i, i, i, i);
        testObject.doSomething(i, i, i, i, i, i);
        i++;
    }

and all works just the same as with deprecated scope storage class.

Even better it disallows passing the variable to functions expecting vanilla Test, it's limiting but for a good reason. There are still issues that should be solved (name clash for one, plus the ability to define default construct Scoped!T) but overall it's OK to me.

I agree Scope has a rightful place in the standard library.


Andrei