A container similar to folly's small_vector would be great to have ( https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md)
On 9 June 2015 at 18:11, Jonathan M Davis via Digitalmars-d < [email protected]> wrote: > 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 > -- -=Miles Stoudenmire=- [email protected] [email protected] http://itensor.org/miles/
