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