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
