On Sat, 03 Oct 2009 10:52:09 +0400, Christian Kamm
<kamm-incasoftw...@removethis.de> wrote:

Tom S wrote:
I think it should be done in userland, not built-in. Here's a
proof-of-concept implementation:

I agree and also had a go at it a few months back:
http://www.digitalmars.com/d/archives/digitalmars/D/scope_as_template_struct_82104.html

What about alignment issues though? I think we need to force that byte array
with the class data to have the same alignment restrictions as the class
data.



Yes, it is possible, but their use is dangerous without non-nullable *value* types, because user is not forced to initialize it in ctor.

I believe compiler should complain unless user explicitly assigns a value to such variable:

class Foo
{
      Scope!(Bar) bar;

      this()
      {
          //bar.construct(args); - a no-go, use of an unassigned variable.
          // How can compiler distinguish between bar.constract(args),
          // which is allowed to be called on non-constructed object, and
          // bar.doSomething(), which is not?
          // Besides, it hides possibly existing Bar.construct method.

// bar = new Bar(args); - desirable syntax, but impossible w/o compiler help

          bar = Scope!Bar(args); // explicitly initialized
          bar.doSomething();     // okay
      }
}

I think we should either drop "scope" feature altogether in favor of library solution, or extend it to scope classes. The former is not possible unless there is a way to implement scope(exit), scope(success) and scope(failure) in library, which I am not aware of.

That's why I prefer built-in scope class members ATM.

Be it implemented in a compiler, should it be rebindable or not? Andrei mentioned that it's probably not, but then it creates an inconsistency with local scope variable (those are rebindable).

Another difference is that currently the following code is allowed:

Foo createFoo() {
    return new FooDerivative();
}

scope Foo foo = createFoo(); // allocates on heap anyway, which might be confusing

Shouldn't compiler complain in case scope variable is heap-allocated?

Shall we unify the two concepts (local and class member scope variables)? If yes, then how?

Reply via email to