D2's feature set?

[Steve Schveighoffer]

On Sat, 06 Jun 2009 11:26:37 -0400, Jarrett Billingsley wrote:

> On Sat, Jun 6, 2009 at 11:17 AM, Steven
> Schveighoffer<schveiguy at yahoo.com> wrote:
>>>
>>> You need to do escape analysis and whole program analysis to determine
>>> whether there are aliases to a scope member. Failing that, it's pretty
>>> easy to introduce bugs that are difficult to find.
>>
>> Not really.  A scope member would be placed in the same memory block as
>> the owner class.  So an alias to the member would be the same as an
>> alias to the owner class because the same memory block would be
>> referenced.  Both wouldn't be collected until neither is referenced.
> 
> Regardless of how/where it's allocated, Chris is still right, unless
> 'scope' becomes a type constructor instead of a storage attribute.
> Consider:
> 
> class A
> {
>     void fork() { writeln("fork!"); }
> }
> 
> class B
> {
>     scope A a;
>     this() { a = new A(); }
> }
> 
> A a;
> 
> void foo()
> {
>     scope b = new B();
>     a = b.a; // waaait
> }
> 
> void main()
> {
>     foo();
>     a.fork(); // AGHL
> }
> 
> If it were impossible to assign a "scope A" into an A, this wouldn't be
> a problem.  Or, full escape analysis, either way.

You are looking at a different problem.  This problem already exists:

A a;
void foo()
{
  scope al = new A();
  a = al;
}

I'm talking about scope members, that is, members whose storage is 
contained within the owner.  This allows destructors to access members 
before the members' memory is destroyed, because both the member and the 
owner's memory is destroyed at the same time.

There would have to be some special treatment for a scope member by the 
compiler -- the member should not be rebindable, and I think you would 
not need to store a separate reference to the member, because it's 
reference address is statically decided.  In other words, yes, scope 
members would be treated differently, but I don't think scope needs to be 
a type constructor for that.

-Steve