scope class members -> in-situ

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Fri, Oct 2, 2009 at 8:33 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> I think this has been discussed in this group already.
>>
>> An object storing another object needs two allocations:
>>
>> class A { ... }
>> class B {
>>   A a;
>>   this() {
>>      a = new A;
>>   }
>> }
>>
>> auto b = new B; // two allocations
>>
>> I'm thinking of using "scope" in this situation to imply in-situ storage:
>>
>> class B {
>>   scope A a;
>>   this() {
>>      a = new A;
>>   }
>> }
>>
>> Now the A member actually lies inside of B - no more indirection. That means
>> the constructor needs special scrutiny, in particular a cannot be null
>> because that wouldn't make much sense.
>>
>> What do you think?
> 
> I think it would be nice, but there are enough issues that I'm not
> convinced that saving a few allocations is worth it.
> 
> Mainly what happens if you do   someB.a = someOtherA  later on?
> 
> The answer to that might be different than how you treat  someB.a = new A().
> 
> The latter could be converted into a placement new.   But the former
> has to still point to the original someOtherA to maintain proper
> reference semantics.
> 
> You can sidestep these issues by saying that a scope A in a class is
> not rebindable.  But that no doubt cuts out some useful cases.

Yah, the idea was to make it not rebindable. Initially I even thought of 
using "final" instead of "scope".

> Another option would be to make "scope A" reserve space for both a
> pointer to an A and the memory for it.  Then the someB.a is just a
> regular A reference that can be rebound like any other, or made null
> if desired.  It would just leave orphaned memory sitting there if
> rebound to point to some other A.   Or it could use placement
> construction if you assign a new A to it.   (but not if you say
> someB.a = new DerivedFromA()).

Having a reference plus in-situ storage also crossed my mind, but I 
think it would serve corner cases that could best be served by either 
using two allocations, or having the user herself define one reference + 
one scope object.


Andrei