Paralysis of analysis

[Dmitry Olshansky]

On 14.12.2010 22:02, Andrei Alexandrescu wrote:
> I kept on literally losing sleep about a number of issues involving 
> containers, sealing, arbitrary-cost copying vs. reference counting and 
> copy-on-write, and related issues. This stops me from making rapid 
> progress on defining D containers and other artifacts in the standard 
> library.
>
> Clearly we need to break this paralysis, and just as clearly whatever 
> decision taken now will influence the prevalent D style going forward. 
> So a decision needs to be made soon, just not hastily. Easier said 
> than done!
>
> 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.

Sure thing.
>
> 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.)

What challenges do we face with this approach? Can you please outline 
the mechanics of that controlled lifetime outside the container part, 
e.g. is it by usage of some tricky wrappers?

>
> 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.

Your change looks like going with third option, am I correct?

>
> * * *
>
> 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.
>
> 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.
>
> Disadvantages:
>
> - Containers must be dynamically allocated to do anything - even 
> calling empty requires allocation.

I was of impression that you could allocate class instances almost 
anywhere (with help of emplace), it's just that heap being the safe default.

>
> - There's a two-words overhead associated with any class object.
>
> - Containers cannot do certain optimizations that depend on 
> container's control over its own storage.

That must have something to do with sealed container being wrappers over 
unsealed ones, so as I observe your change implies not only a change to 
final classes.  Clearly something is missing in your post can you please 
be more specific on that change?

>
>
> What say you?
>
> Andrei


-- 
Dmitry Olshansky