D2's feature set?

[Steve Schveighoffer]

On Sat, 06 Jun 2009 10:57:08 -0700, Brad Roberts wrote:

> Steven Schveighoffer wrote:
>> On Sat, 06 Jun 2009 09:35:15 -0400, Christopher Wright
>> <dhasenan at gmail.com> wrote:
>> 
>>> Kristian Kilpi wrote:
>>>>  I think I shouldn't post this because I could very well start one of
>>>> those mega-threads... :D
>>>>  Of course, only Walter & Co know what D2 will include when it's
>>>> finally 'released'. Concurrency stuff has been developed lately. But
>>>> something more? Or is that it? What do you think?
>>>>   I haven't thought about it too much, but lets say something... ;)
>>>>  1) Scoped members. For example:
>>>>  class Foo
>>>> {
>>>>      scope Bar bar;  // gets destructed with Foo object
>>>> }
>>>
>>> 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.
>> 
>> It's the equivalent of this in C++:
>> 
>> class Bar
>> {
>> }
>> class Foo
>> {
>>   Bar bar;
>> }
>> 
>> The only issue left to decide is how the member is initialized.  There
>> must be some rules, like if bar has no default constructor, it must be
>> new'd in the constructor.  And it can't be rebound.
>> 
>> -Steve
> 
> Can't work like that since it's subject to the object slicing problem. 
> Class size can't be known in advance since subclasses can add an
> arbitrary amount of additional storage requirements.  If you restrict it
> to structs or other value types, then it could work but would be awfully
> restrictive.

Structs are already part of the class data.  I don't believe something 
like this will work

class A : B {}
class C
{
   scope A a;
   this() {a = new B;}
}

It would not work any differently than how scope classes are allocated on 
the stack.  Just instead of the stack, you are allocating the scope class 
inside the class data instead of a stack (well, if the owner class was 
allocated on the stack, it would be on the stack).  You would not have 
any slicing issues.  Either:

1. The class contains not only the member class data but also a reference 
to it (and in this case, the reference could be re-bound).
2. The class can not reassign the member once it is assigned (i.e. head-
const).  When it passes the class member to a function, the compiler 
would pass a reference to the contained class data.  This is what I was 
expecting.

The benefit would be that you can control the destruction order of the 
members in the owner's destructor.

-Steve