In the new world of ImportC giving direct access to C in D 2.108, and function pointer types and function types being imported into D source automatically from the D compilation of C headers, there is a case to be made for a maximum of information about the declarations in those headers being made available to D. Specifically the parameter names in declarations of functions (and function pointers) in such headers.
Right now, given a function's signature, std.traits.ParameterIdentifierTuple
produces the names of its parameters at compile time.
int foo(int num, string name, int);
static assert([ParameterIdentifierTuple!foo] == ["num", "name", ""]);
However, there is no way (so far as I have been able to ascertain) to extend this behavior to some frequently occurring other ways function names may be associated with signatures in C header files.
A common example is a Vtable defined in a C header file, being the C representation of an OOP-something defined for C++. When compiled with ImportC, as __cplusplus
is not #define
d, this is what D gets made available automatically.
In effect this is a struct with the field names being the names of function pointers each of which is given a signature that contains parameter names. In effect the signatures of several functions are given whose names are the names of the struct's fields.
In this situation, right now ImportC does indeed preserve the names of the parameters, just as it does for the vanilla function foo above. But as the names are struct field names, there is no name that is the name in a signature, and ParameterIdentifierTuple
has no function name to be applied to, making the parameter names inaccessible.
How was I able to say that ImportC preserves those names? It is still possible to get the type of the function pointed to by a struct field and see it using pragma(msg,_)
and the parameter names are present: good news, for those of us trying to get the parameter names from a signature as a practical matter. However, applying ParameterIdentifierTuple
to a function type (or a function pointer type too) produces no names, despite the above indicating they are recorded in the type.
Parameter names and their connection to the D types of function pointers and functions is a vexed question. On the one hand, parameter names do not affect type equality, so a purist may argue they should not be a part of the type. The force of this is blunted somewhat by the fact that we may simply define type equality to ignore parameter names. Yet the parameter names indicate something about the source of the function type definition that is in this sense not a part of the type. This is ugly.
As a practical matter right now, it would be good if parameter names continue to be stored in the type of a function or function pointer, as this is (so far as I have been able to ascertain) the only way they are accessible in D. Right now I am extracting them using CTFE!
Again, as a practical matter, it would be good if he purist view of function and function pointer types could be put aside and ParameterIdentifierTuple
be permitted to work on function and function pointer types, at least until there is an alternative way for compile-time retrieval of parameter names from ImportC. Is there an operational downside to this?
What could an alternative way to get parameter names from ImportC be? Either existent now, or a language addition?