std.container: fork in the road

[Sebastiaan Koppe via Digitalmars-d]

On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu 
wrote:
> 2. Do break compatibility of containers, mainly by taking 
> advantage of them being under-documented. In a way we wouldn't 
> break much because not much has been specified. There are, 
> however, parts where we'd need to change specification.
>
> 3. Leave std.container alone and move forward with 
> std.experimental.collection. I am confident the language and 
> its endorsed idioms have reached enough maturity to not make 
> this addition into a regular event.
>
>
> Andrei

2. would break code, but I feel 3. would break semantics; 
collection != container. A container might contain 2 collections, 
and a collection might span 2 containers.

I can have a collection where part of the data is stored in one 
kind of container, and other parts are stored in other types of 
containers, to exploit certain properties of containers against 
data access patterns. Also, in std.collection I might expect 
push-based collections. No, I consider containers to be at a 
lower level of abstraction compared to collections.

I am favoring std.deprecated. Although the poor chap compiling 
old code in a few years from now is going to have a great time 
figuring out he needs to change an import. It'll take him half a 
day to type 12 goddamn letters :)