Container hierarchy vs. container types

[Walter Bright]

Andrei Alexandrescu wrote:
> I decided to let no assumption unchallenged and got back to the 
> question: do we really need a container _hierarchy_? How much joy and 
> usefulness do people derive from dynamically changing an array with a 
> list under the same interface? Or a rb-tree vs. a binary tree vs. a 
> left-leaning binary tree?

I've never, in 35 years of programming, ever had a need to change the 
container type at runtime. I don't think the thought has ever even 
crossed my mind. I appreciate bearophile's point of runtime profiling 
being used to change the container, but I suggest that such containers 
be internally self-modifying, rather than externally using user-visible 
virtual functions.

I more and more like the idea of having a set of names defined by 
convention that have conventional behaviors, in other words, duck 
typing. It's infinitely extendable and flexible without needing to 
modify the core library in any way. It also fits right in with D's 
template constraints.

The bit flag approach is not pretty. Furthermore, to add a capability 
means one has to redo that enum in the core library, which is not 
scalable and people don't like making their own custom core libraries. 
Even if they did, it makes for mutually incompatible third party 
libraries. Yuk.