std.container: fork in the road
Meta via Digitalmars-d
digitalmars-d at puremagic.com
Wed Jun 17 06:05:50 PDT 2015
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.
More information about the Digitalmars-d
mailing list