scope class members -> in-situ

Denis Koroskin 2korden at gmail.com
Sat Oct 3 02:59:58 PDT 2009


On Sat, 03 Oct 2009 10:52:09 +0400, Christian Kamm
<kamm-incasoftware at 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?



More information about the Digitalmars-d mailing list