Right after allocators: containers or database connectivity?

[Andrei Alexandrescu via Digitalmars-d]

On 6/9/15 1:56 PM, Steven Schveighoffer wrote:
> 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.

Interesting, I didn't know about that.

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

Regarding projects that we discussed you are considering, I suggest we 
focus on putting std.container in good shape and opt for a redesign only 
if there are great benefits. Also, I think we should stay with 
libc-based I/O.


Andrei