On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Even if we implement the change to be memory-safe, there's
still changes in semantics (e.g. the behavior of orphan ranges
changes). And even if we change behavior that wasn't specified
explicitly in the docs, it's still a change in behavior. The
same goes for other functions that remove elements from
containers.
std.container.gc and std.container.rc?
Oh, and one more thing I noticed:
* The documentation is appallingly bad, making std.container
worse than non-existent. We have a liability squared to deal
with here. I've pretended to myself I hadn't implemented SList
and it was nigh impossible to use it competently from
documentation alone, let alone understand the deeper
architectural underpinnings that apply to other containers.
This is another manifestation of the systemic problem of our
community that's been discussed here in the past - there are
matters that greatly affect negatively the uptake of D, yet
they stay unresolved for literally months and years in spite of
being trivially simple. For a potential user who sees today
"std.container" in the library offering list, the subsequent
click will lead almost by necessity to a vote of non-confidence.
I will take a look at the docs over the next couple of days and
see if I can improve them.
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better alongside them.
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.
3 seems to be the best option, or 1 in a pinch. I don't think 2
is really necessary if std.container is separated into GC'd and
RC'd containers.
As an aside, I've only used std.container once, to port some
trivial Java code to D. I ended up spending far more time than
was necessary trying to get my code to even compile, due to
issues such as RedBlackTree!(int, (a, b) => a < b) and
RedBlackTree(int, (a, b) => a < b) being two different types. It
did not leave me with a good impression of std.container.
