scope class members -> in-situ

[Yigal Chripun]

On 03/10/2009 11:59, Denis Koroskin wrote:
> 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?

I think scope should be completely removed from the language. it seems 
to me like the register keyword in C.
this aspect of memory management would be better off as an optimization 
by the compiler when applicable instead of user specified.

consider:
class B {...}
class A {
   // desirable syntax:
   // const B obj;
   NonRebindable!B obj; // assume language support instead of template

   this (args) { obj = new B(args); }
}

since obj is non-rebindable the compiler can optimize this without 
requiring the user to specify "scope".

local variables in a function would have similar semantics:

void foo() {
   NonRebindable!B = new B;
   ..
}

final classes and immutables can also scoped.

unless the user wants to explicitly handle memory with C malloc, I think 
the best thing would be to separate lifetime management from memory 
management. the programmer defines the lifetime of the data while the 
language/compiler/runtime handle all other aspects like choosing stack 
vs. heap, allocating and de-allocating (GC)