What library functionality would you most like to see in D?

[Piotr Szturmaj]

Jonathan M Davis wrote:
> I think that it would be useful to query the community for what piece of
> library functionality they don't currently have in D and would most like to
> see. For instance, there is no official logging framework in D or any 3rd party
> libraries which do it AFAIK. So, that could be one type of functionality that
> you may like to see. Now, there is a prospective implementation for std.log
> which shouldn't be all that far away from being reviewed, so listing that here
> wouldn't be all that useful, since it's on its way. But what other major
> functionality do you miss in D that other languages' that you use have
> available in their libraries?
>
> My hope here would be that we could get some good ideas going here such that
> we have can have a better idea what type of functionality it would be
> particularly useful to be working on for Phobos or 3rd party D libraries for
> the community, and maybe it'll even get some people to actually go and work on
> these ideas so that we can improve the libraries that we have to work with in
> D. We can always use more help, and we definitely need a richer library
> ecosystem for D. But even just discussing ideas could be of benefit.
>
> So, what major functionality which we don't currently have would you like to
> see in either Phobos or in a 3rd party library so that you could use it in
> your D programs?
>
> - Jonathan M Davis

1. Cryptography (I already wrote all SHA hash implementations and HMAC, 
they will be open sourced under Boost license, I'm also working on 
Rijndael/AES impl.)

some of the proposed namespaces (just thinking loud):

std.crypto.cipher - block and stream ciphers
std.crypto.hash - message digests (SHA1, RIPEMD, ...)
std.crypto.mac - message auth codes like HMAC, CMAC, UMAC
std.crypto.mode - block cipher modes like CBC, GCM, ...
std.crypto.padding - padding schemes
std.crypto.pki - asymmetric cryptography (RSA), PKI
std.crypto.x509 - certificate support

2. Easy to use non-GC threads for soft real time support. Non-GC threads 
must not be suspended by the GC and they must support some kind of 
reliable communication with normal (GC) threads. This should be similar 
to IPC, where there's no shared memory between GC and non-GC threads.

Consider running two separate programs, one written in D with GC support 
and one written in plain C. These programs communicate with each other 
using some IPC mechanism. The latter is never suspended.
The whole point is to make equivalent of this configuration in a single 
executable using mixture of GC and non-GC threads.