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 :)
