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

[Alex Rønne Petersen]

On 31-07-2011 07:27, 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

Here's a bunch of ideas, listed in no particular order...

--

* Native code generation:

I know this is quite a stretch for the standard library, but one thing 
I'm kind of missing at the moment is a uniform way to generate native 
machine code.

This could be a useful piece of functionality for any application that 
takes code and just-in-time compiles it, in order to subsequently 
execute it. It could even be abstract enough to be reused as a 
general-purpose code generation library for executable files. I'm sure 
compiler/interpreter/VM writers alike would find this useful; I know I 
would. I'm currently in the process of writing a compiler infrastructure 
which will be capable of spitting out x86(-64) executable files, as well 
as executing code right in memory. In order to do this, I have to 
implement a code generation library for all of x86(-64); this is not a 
problem, but I'm sure others have had to do this before me (and will in 
the future). Standard facilities for this would make compiler 
engineering in D much easier.

All this being said, this would probably be scarcely used and thus might 
not deserve much priority; I'm sure there are other things in much 
greater need of work at the moment. I just wanted to put this out there, 
at least.

If this is something that would be desirable for the standard library, I 
would have no problem writing it for Phobos rather than my specific project.

* Concurrency:

Another thing I'd like to see is a better way of doing message-passing. 
Since D threads are, effectively, OS threads, spawning lots of actors is 
not as cheap as one would like. I'd like some way to spawn lightweight 
threads that integrate with std.concurrency so that actor systems can be 
modeled naturally (a la Erlang), rather than throwing several actors 
into one thread. I'm not sure how heavy fibers are in D, but perhaps it 
could be implemented on top of those?

It would be even more awesome if std.concurrency was expanded to 
actually support distributed message-passing in some way; even 
heavyweight threads would be acceptable as long as the system could 
scale horizontally.

* GPU/graphics:

Standard library support for OpenGL and OpenCL would be a great way to 
make D more accessible for GPU-oriented programmers, I would think. 
Wrapping these libraries would probably be rather trivial. DirectX could 
of course be wrapped too, but I suppose a cross-platform interface would 
be better.

* Configuration:

AFAIK, D has no standard way of doing configuration at the moment. I 
don't know whether people see this as a problem or not. On one hand, 
just asking some configuration parser to fetch values for you is very 
convenient, but on the other hand, people might not like having some 
sort of "official D configuration format". Personally, the former seems 
appealing to me, as configuration parsing is the last thing I want to 
work on in my projects. ;)

* Cryptography:

D could definitely use more implementations of cryptographic algorithms. 
Wrapping OpenSSL might be a wise thing to do.

* Compiler interface:

Some primitive sort of interface to invoke the compiler on a set of 
files with certain options could be useful to invoke child processes 
with code compiled on the fly. This would of course demand that DMD is 
installed, but I don't think that's a problem for apps where doing this 
in the first place is a good idea.

* Lexing and parsing:

Standard facilities for these tasks could be very useful. Perhaps D 
could get its own dlex and dyacc or some such tools. Personally, I 
prefer sticking to LL(1), but LALR is generally more convenient and 
flexible, and thus I'd suggest something YACC/ANTLR-like.

(I know this doesn't have much to do with Phobos per se, but I figured 
I'd mention it.)

* Asynchronous sockets:

For high-performance servers, asynchronous sockets utilizing 
functionality such as IOCP on Windows is important.

* Audio/video:

Interfaces to a library such as Libav could be included in Phobos.

* Serialization:

Some kind of serialization library could be useful. It could probably 
use compile-time reflection to figure out what kind of code to generate 
for a type, although my knowledge in D's CTR is not really sufficient to 
judge this.

--

Personally, what I'd like to see done first would be native code 
generation, concurrency, and cryptography.

- Alex