Right after allocators: containers or database connectivity?

[Steven Schveighoffer via Digitalmars-d]

On 6/9/15 4:40 PM, Vladimir Panteleev wrote:
> On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
>> Please help me choose what to work on next.
>
>> One would be a good pass of std.container, in particular (a) a design
>> review with the DbI glasses on; (b) better documentation - sadly it
>> seems to me so inadequate as to make containers themselves unusable;
>> (c) investigate use of UFCS - std.container's design predates UFCS yet
>> is a perfect fit for it, and most likely other cool language
>> improvements we've added since.
>
> No plans to use std.allocator? I think containers are the next logical
> step after allocators, and will also serve as a proving ground for the
> allocator API.

I agree. In fact RedBlackTree from dcollections used an allocator, and 
the apparatus is still pretty much in std.container.rbtree.

Part of me hoped to make another stab at getting dcollections suitable 
for inclusion in Phobos (much of my design philosophy has changed over 
the last few years), but I don't think I have the cycles :(

-Steve