Paralysis of analysis

[Steven Schveighoffer]

On Tue, 14 Dec 2010 14:02:34 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> I continue to believe that containers should have reference semantics,  
> just like classes. Copying a container wholesale is not something you  
> want to be automatic.

I agree.

> I also continue to believe that controlled lifetime (i.e.  
> reference-counted implementation) is important for a container.  
> Containers tend to be large compared to other objects, so exercising  
> strict control over their allocated storage makes a lot of sense. What  
> has recently shifted in my beliefs is that we should attempt to  
> implement controlled lifetime _outside_ the container definition, by  
> using introspection. (Currently some containers use reference counting  
> internally, which makes their implementation more complicated than it  
> could be.)

I think ref counting needs to be fleshed out more before we use it.  I'm  
not of the mind that phobos should use concepts that are not properly  
implementable based on the current compiler/runtime design in hopes that  
the design gets better.  I'd rather design it to work now, and redesign  
later if the opportunity becomes available.

> Finally, I continue to believe that sealing is worthwhile. In brief, a  
> sealing container never gives out addresses of its elements so it has  
> great freedom in controlling the data layout (e.g. pack 8 bools in one  
> ubyte) and in controlling the lifetime of its own storage. Currently I'm  
> not sure whether that decision should be taken by the container, by the  
> user of the container, or by an introspection-based wrapper around an  
> unsealed container.

I agree that a sealed container is worthwhile.  I think it needs to be the  
container's decision (for instance, the pack bools into bits must be a  
container decision).

> That all being said, I'd like to make a motion that should simplify  
> everyone's life - if only for a bit. I'm thinking of making all  
> containers classes (either final classes or at a minimum classes with  
> only final methods). Currently containers are implemented as structs  
> that are engineered to have reference semantics. Some collections use  
> reference counting to keep track of the memory used.

I think this is the right move.  Responding to pros/cons below:

> Advantages of the change:
>
> - Clear, self-documented reference semantics
>
> - Uses the right tool (classes) for the job (define a type with  
> reference semantics)
>
> - Pushes deterministic lifetime issues outside the containers  
> (simplifying them) and factors such issues into reusable wrappers a la  
> RefCounted.

- exposes the issue of default initialization by disallowing that.  This  
is the problem of passing an uninitialized struct into a function and  
having the function not be able to affect the original.  A class has a  
more defined and better understood lifetime cycle -- nothing exists until  
new is used.

- no more need to "check if it's valid" in every member function.

> Disadvantages:
>
> - Containers must be dynamically allocated to do anything - even calling  
> empty requires allocation.

Can't emplace work to fix this?  At least for cases where you don't need  
the container to live beyond the scope of a function.

> - There's a two-words overhead associated with any class object.

I assume this is in response to containers of containers?  It's actually  
96 bits, because the minimal memory block size is 16 bytes.  Therefore, a  
container which could potentially have a 1-word footprint must have 4  
words.  For 64-bit, I'm unsure of the proposed GC implementation.

I have some ideas to solve this, but they are abstract in my head, I  
haven't solidified them enough to start a discussion yet.  Short story --  
I think if we clearly separate the implementation from the container, we  
might be able to combine implementations in a minimal way.

> - Containers cannot do certain optimizations that depend on container's  
> control over its own storage.

Can you explain this further?

-Steve