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/[email protected]
