On Tuesday, 9 June 2015 at 22:37:32 UTC, Andrei Alexandrescu wrote:
> On 6/9/15 3:11 PM, Jonathan M Davis wrote:
>> And containers are really the main place, I think, where iterators
>> actually do better than ranges.
>
> I think iterators would need to add huge value to warrant addition. -- Andrei

I don't disagree. I think that we should stick with ranges. I just think that this is one of the few areas where ranges are actually worse than iterators, whereas in most other areas, they're better. The result is that some of the idioms that are used with iterators in C++ become increasingly unwieldy with ranges - finding an element and removing it from the container is probably the simplest example.

So, I think that the main change that we need to make in that regard to std.container is to have more functions which operate based on keys or values passed to the function rather than just having range-based functions. So, we'd have functions like removeFirst, removeLast, removeAll, etc. which take values rather than having all of the container functions be range-based. Iterators wouldn't need to enter into it at all.

- Jonathan M Davis

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
> ...

I think the overall benefit would be from containers, as everyone uses containers.

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
> Please help me choose what to work on next.
>
>
> Andrei

As others have said - definitely containers! A lot more applications use them.

There is too much differences between databases (SQL and No-SQL) to cover them effectively under a single interface. Every language has at least a couple of libraries that take very different approaches with different levels of abstraction and so on. There is no single correct design. So for now I think it it's better to leave databases to dub.

On the other hand containers is the right place to do an opinionated design which integrates well with other parts of Phobos (std.algorithm, std.range, std.ex.allocator and maybe some policy-based design for logging backed by std.ex.logger). See Brad Anderson's comment other for more specific action items.

One other important thing that needs to be addressed is library-based AA. Igor Stepanov and Martin Nowak (and others) have been trying to solve this for a long time but there some issues that may require breaking changes. This area requires more serious attention because there is no easy solution. Also currently dynamic arrays, exceptions and other language features are also heavily tied to the GC, preventing them to be used in projects for which GC is not appropriate.
After all the good work that has gone in std.allocator, it's a shame if two of D's most used built-in types can't benefit. The more we can untie the implementation of dynamic arrays from dmd and druntime, the faster we can deliver improvements in those areas.
There were some nice ideas here[1] which I really hope to be realized. So any ideas on how to move more the implementation of AAs and dynamic arrays to user-land (instead of compiler-land), so one could easily decide on the memory management strategy and data-structure that back the AA, without replacing all usages of the built-in AA with a library type from std.container?

It may be more about implementation than language changes, but recently I was thinking about what a language enhanced may look like:

{
    // Swap the implementation of built-in AAs
    //and use HashMap instead in this scope
    alias __aa(K,V) = std.container.hm.HashMap!(K, V);

    ...
}

Or:

// Templatize a module by memory management strategy (and more).
// Like specifying versions on the command-line, but
// as powerful as templates:

enum desired_mms = MMStrategy.refCounting;
import image_processing!desired_mms : Image;
// Image is a refcounted or GC class, depending on
// the module template parameter

[1]: http://beta.forum.dlang.org/thread/m0bdgg$1t7j$1@digitalmars.com

On Wednesday, 10 June 2015 at 00:26:23 UTC, ZombineDev wrote:
> After all the good work that has gone in std.allocator, it's a shame if two of D's most used built-in types can't benefit. The more we can untie the implementation of dynamic arrays from dmd and druntime, the faster we can deliver improvements in those areas.

Here I meant mostly Associative arrays and perhaps dynamic array.

On Wednesday, 10 June 2015 at 00:26:23 UTC, ZombineDev wrote:

> // Templatize a module by memory management strategy (and more).
> // Like specifying versions on the command-line, but
> // as powerful as templates:
>
> enum desired_mms = MMStrategy.refCounting;
> import image_processing!desired_mms : Image;
> // Image is a refcounted or GC class, depending on
> // the module template parameter
>
> [1]: http://beta.forum.dlang.org/thread/m0bdgg$1t7j$1@digitalmars.com

Why not something like

  alias HashMap (T) = std.container.HashMap!(T, MMStrategy.refCounting)

which is available now, just depends on how the template arts for a given container are set up.

Well I got this working. Please review:

https://github.com/D-Programming-Language/phobos/pull/3398


Andrei

On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
> Please help me choose what to work on next.
>
>
> Andrei

My vote goes for std.containers!

Anyway imho std.database should be a generic database module. Not a sql-oriented one. ODBC is sql-oriented! If not, call it std.sql or std.database.sql.

Andrea

On 2015-06-09 20:49, Brad Anderson wrote:

> 1.  vector/array
> 2.  hash map
> 3.  hash set
> 4.  flat map
> 5.  flat set
> 6.  map
> 7.  set
> 8.  deque
> 9.  stack
> 10. queue
> 11. linked list
> 12. hash multimap
> 13. hash multiset
> 14. flat multimap
> 15. flat multiset
> 16. multimap
> 17. multiset
> 18. priority queue


> I think RedBlackTree isn't a very good name though. It's long and is an
> implementation detail.

In that case you would need to remove "hash" and perhaps "flat" from all containers to be consistent. Also "linked list" would be just "list". It would be difficult to come up with better names since there would be name clashes.

-- 
/Jacob Carlborg

On Wednesday, 10 June 2015 at 07:50:24 UTC, Jacob Carlborg wrote:
> On 2015-06-09 20:49, Brad Anderson wrote:
>
>> 1.  vector/array
>> 2.  hash map
>> 3.  hash set
>> 4.  flat map
>> 5.  flat set
>> 6.  map
>> 7.  set
>> 8.  deque
>> 9.  stack
>> 10. queue
>> 11. linked list
>> 12. hash multimap
>> 13. hash multiset
>> 14. flat multimap
>> 15. flat multiset
>> 16. multimap
>> 17. multiset
>> 18. priority queue
>
>
>> I think RedBlackTree isn't a very good name though. It's long and is an
>> implementation detail.
>
> In that case you would need to remove "hash" and perhaps "flat" from all containers to be consistent. Also "linked list" would be just "list". It would be difficult to come up with better names since there would be name clashes.

It would be useful to have trees, heaps, (un)directed graphs...

On Tuesday, 9 June 2015 at 17:56:57 UTC, luminousone wrote:
> On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
>> My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly.
>>
>> After that I'm ready for some major library work, and I had two things in mind.
>>
>> 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.
>>
>> The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options.
>>
>> For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford).
>>
>> So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up.
>>
>> Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice!
>>
>> It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there!
>>
>> Please help me choose what to work on next.
>>
>>
>> Andrei
>
> I would think a good database lib would depend on a good container lib, So IMO, the order is self evident.
>
> 1000+ to containers.

Yep. Containers.

containers + right allocation strategy => interfacing to data base with the right containers