I like to create code that automates much of the manual labor
that we, as programmers, are generally forced to do. D generally
makes much of this work automatable. For example, I have created
the following code which makes loading dlls similar to libs:
/* Import DLL functions in to type T. The following example shows
@("DLLImport") public static extern(Windows)
void* function(GdkWindow *window)
// Fixes static functions and function pointers to point to their
void DLLImport(alias T)()
import core.sys.windows.windows, std.conv, std.meta, std.traits;
foreach(fname; __traits(allMembers, T))
mixin("enum isf = isFunction!(T."~fname~");");
mixin("enum isfp = isFunctionPointer!(T."~fname~");");
mixin("enum attrs = __traits(getAttributes,
static if ((isf || isfp) && attrs.length == 2 && attrs ==
auto dllName = attrs;
if (dllName !in DLLs)
auto dll = DLLs[dllName];
if (dll == null)
assert(0, "Cannot load DLL
auto func = GetProcAddress(dll, fname);
mixin("auto p = cast(void**)&"~T.stringof~"."~fname~"; *p =
But this got me thinking that we don't even need to have to
specify the function in D, hell, they already exist in the lib
and we are just duplicating work.
What if, at compile time, D could get all the functions and their
type information and build a class for them for us? We could then
just write something like
@("DLLImport") string libgdk = "libgdk-3-0.dll";
and have some ctfe meta functions extract all the function from
libgdk and insert them in to the struct.
There are two problems with this, one easy and one
hard/impossible(which would be easy if people were intelligent
enough to have foresight):
1. Get the dll function by name from the dll at compile time.
This would probably require manually reading the dll file and
scanning for the function.
2. Get the type information to build a declaration. This is
probably impossible since dll's do not contain the type
information about their parameters and return type(or do they?).
If they did, it would be easy. I would suggest that all dll's
generated by D include this information somewhere and an easy way
to extract it for future programmers so such things could be
Alternatively, maybe a master database could be queried for such
information by using the function names and dll name? I don't
know if D has network capabilities at compile time though.
Alternatively, completely scrap the lethargic way things are done
in the name of backwards compatibility and $$$ and do things
right(learn from the past, stop repeating same mistakes, etc).
Sure it's a lot of work, but in the end is far less than one
thinks considering the increased productivity... but I guess the
we gotta keep buying the kids christmas presents.