Right after allocators: containers or database connectivity?

[Miles Stoudenmire via Digitalmars-d]

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 <
digitalmars-d at puremagic.com> 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=-
   miles.stoudenmire at gmail.com
   emiles at pitp.ca
   http://itensor.org/miles/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150609/9a3aa5fb/attachment.html>