Right after allocators: containers or database connectivity?

[ZombineDev via Digitalmars-d]

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