Right after allocators: containers or database connectivity?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu 
wrote:
> 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.

Honestly, I think that std.container's API is a very good start. 
The main problems lie with ranges. We need to make sure that all 
of the range-based functions are consistent (e.g. accepting 
Take!R, TakeOne!R, TakeExactly!R, etc. where R is the range type 
for that container - we do that to some extent, but we're not 
consistent about it), and we need to add more functions that 
don't use ranges - in particular, remove functions which remove 
keys or values without having to use a range to do it. Honestly, 
while it's flexible, it's not exactly the finest hour for ranges 
when you have to do something like

container.remove(container[].find(value).takeOne());

just to remove a value for the container. Most folks just want to 
do something like

container.removeFirst(value);

And containers are really the main place, I think, where 
iterators actually do better than ranges. So, while I definitely 
want the containers to continue to support ranges, I think that 
we should do a better job of having alternative functions which 
don't involve ranges if they don't need to for many of the basic 
cases. Then the simple cases won't have to use ranges just to do 
stuff like remove elements, and generic code and more complicated 
cases can use ranges as appropriate.

But in general, while I do think that some polishing is needed 
for the std.container API, I also think that it's a very solid 
start.

- Jonathan M Davis