![\"Digital](\"https:\/\/dlang.org\/blog\/wp-content\/uploads\/2016\/08\/d6.png\")
<\/p>\n<\/p>\n
A while ago, Andrei Alexandrescu started a thread in the D Programming Language forums, titled “Perfect forwarding”<\/a>, about a challenge which came up during the July 2020 beerconf<\/a>:<\/p>\n \nWrite an idiomatic template Several people proposed solutions. In the course of the discussion, it arose that there is sometimes a need to alter a function’s properties, like adding, removing, or hanging user-defined attributes or parameter storage classes. This was exactly the problem I struggled with while trying to support all the bells and whistles of D functions in my Eventually, I created a module that helps with this problem and contributed it to the bolts meta-programming library<\/a>. But before we get to that, let’s first take a closer look at function generation in D.<\/p>\n I speculate that many a programmer who is a moderately advanced beginner in D would quickly come up with a mostly correct solution to the “Perfect forwarding” challenge, especially those with a C++ background who have an interest in performing all sorts of magic tricks by means of template meta-programming. The solution will probably look like this:<\/p>\n This solution is not perfect, as we shall see, but it is not far off either. It covers many cases, including some that a beginner may not even be aware of. For example, It even handles user-defined attributes (UDAs)<\/a> on parameters:<\/p>\n Speaking of UDAs, that’s one of the issues with the solution above: it doesn’t carry function<\/em> UDAs. It also doesn’t work with functions that return a reference. Both issues are easy to fix:<\/p>\n This solution is still not 100% correct though. If the forwardee is This happens because the body of the forwarder consists of a single statement calling the However, Andrei’s challenge was not exactly what we discussed in the previous section. It came with a bit of pseudocode that suggested the template should not be eponymous<\/a>. In other words, I believe that the exact task was to write a template that would be used like this: Though this looks like a small difference, if we want to implement exactly this, a complication arises. In the eponymous The first time I had to do this, I tried the following:<\/p>\n This doesn’t work because a string mixin can only be used to create expressions or statements. Therefore, the solution is to simply expand the mixin to encompass the entire function definition. The token-quote operator Though string mixins are powerful, they are essentially C macros. For many D programmers, resorting to a string mixin can feel like a defeat.<\/p>\n Let us now move on to a similar, yet significantly more difficult, challenge:<\/p>\n Write a class template that mocks an interface.<\/p>\n<\/blockquote>\n For example:<\/p>\n Extrapolating the techniques acquired during the previous challenge, a beginner would probably try this first:<\/p>\n Alas, this fails to compile, throwing errors like:<\/p>\n In other words, This will not handle This will fail with all the functions in the interface that do not<\/em> return a reference.<\/p>\n The reason why everything worked almost magically in the first challenge is that we called the wrapped function inside the template. It enabled the compiler to deduce almost all of the characteristics of the original function and copy them to the forwarder function. But we have no model to copy from here. The compiler will copy some<\/em> of the aspects of the function ( Then, there is the issue of the function modifiers: At this point, there is no other option than to analyze some of the function attributes by means of traits, and convert them to a string to be injected in the string mixin:<\/p>\n If you look at the implementation of So far, we have looked at the function storage classes, modifiers, and UDAs, but we have merely passed the parameter list as a single, monolithic block. However, sometimes we need to perform adjustments to the parameter list of the generated function. This may seem far-fetched, but it does happen. I encountered this problem in my I won’t delve into the details of The Bear in mind, though, that Let’s put aside function attributes and UDAs – we already discussed those in the previous section. The obvious solution then seems to be:<\/p>\n where Does this preserve parameter<\/em> storage classes and UDAs? Unfortunately, it does not:<\/p>\n We lost the The culprit is We see that accessing a parameter individually returns the type… and discards everything else!<\/p>\n There is actually a way to extract everything about a single parameter: use a slice<\/em> instead of an element of the paramneter pack (yes, this is getting strange):<\/p>\n So this gives us a solution for handling the second parameter of But what can we put in place of At this point, we have no other choice but to construct a string mixin once again. Something like this:<\/p>\n This is not quite sufficient though, because it still doesn’t take care of parameter UDAs.<\/p>\nforward<\/code> that takes an alias fun<\/code> and defines (generates) one overload for each overload of fun<\/code>.\n<\/p><\/blockquote>\nopenmethods<\/code> library.<\/p>\nThe Good<\/h2>\n
template forward(alias fun)\r\n{\r\n import std.traits: Parameters;\r\n static foreach (\r\n ovl; __traits(getOverloads, __traits(parent, fun), __traits(identifier, fun))) {\r\n auto forward(Parameters!ovl args)\r\n {\r\n return ovl(args);\r\n }\r\n }\r\n}\r\n\r\n...\r\n\r\nint plus(int a, int b) { return a + b; }\r\nstring plus(string a, string b) { return a ~ b; }\r\n\r\nassert(forward!plus(1, 2) == 3); \/\/ pass\r\nassert(forward!plus("a", "b") == "ab"); \/\/ pass<\/pre>\nforward<\/code> handles the following function without dropping function attributes or parameter storage classes:<\/p>\nclass Matrix { ... }\r\n\r\nMatrix times(scope const Matrix a, scope const Matrix b) pure @safe\r\n{\r\n return ...;\r\n}\r\n\r\npragma(msg, typeof(times));\r\n\/\/ pure @safe Matrix(scope const(Matrix) a, scope const(Matrix) b)\r\n\r\npragma(msg, typeof(forward!times));\r\n\/\/ pure @safe Matrix(scope const(Matrix) _param_0, scope const(Matrix) _param_1)<\/pre>\nstruct testParameter;\r\n\r\nvoid testPlus(@testParameter int a, @testParameter int b);\r\n\r\npragma(msg, typeof(testPlus));\r\n\/\/ void(@(testParameter) int a, @(testParameter) int b)\r\n\r\npragma(msg, typeof(forward!testPlus));\r\n\/\/ void(@(testParameter) int a, @(testParameter) int b)<\/pre>\n
template forward(alias fun)\r\n{\r\n import std.traits: Parameters;\r\n static foreach (ovl; __traits(getOverloads, __traits(parent, fun), __traits(identifier, fun)))\r\n {\r\n @(__traits(getAttributes, fun)) \/\/ copy function UDAs\r\n auto ref forward(Parameters!ovl args)\r\n {\r\n return ovl(args);\r\n }\r\n }\r\n}<\/pre>\n@trusted<\/code>, the forwarder will be @safe<\/code>:<\/p>\n@trusted void useSysCall() { ... }\r\n\r\npragma(msg, typeof(&useSysCall)); \/\/ void function() @trusted\r\npragma(msg, typeof(&forward!useSysCall)); \/\/ void function() @safe<\/pre>\nuseSysCall<\/code> function. Since calling a trusted function is safe, the forwarder is automatically deemed safe<\/a> by the compiler.<\/p>\nThe Bad<\/h2>\n
forward!fun.fun(...)<\/code>. Here is the pseudocode:<\/p>\n\/\/ the instantiation of forward!myfun would be (stylized):\r\n\r\ntemplate forward!myfun\r\n{\r\n void myfun(int a, ref double b, out string c)\r\n {\r\n return myfun(a, b, c);\r\n }\r\n int myfun(in string a, inout double b)\r\n {\r\n return myfun(a, b);\r\n }\r\n}<\/pre>\nforward<\/code>, we did not need to create a new identifier; we simply used the template name as the function name. Thus, the function name was fixed. Now we need to create a function with a name that depends on the forwardee’s name. And the only way to do this is with a string mixin<\/a>.<\/p>\ntemplate forward(alias fun)\r\n{\r\n import std.format : format;\r\n import std.traits: Parameters;\r\n enum name = __traits(identifier, fun);\r\n static foreach (ovl; __traits(getOverloads, __traits(parent, fun), name)) {\r\n @(__traits(getAttributes, fun))\r\n auto ref mixin(name)(Parameters!ovl args)\r\n {\r\n return ovl(args);\r\n }\r\n }\r\n}<\/pre>\nq{}<\/code> is very handy for this:<\/p>\ntemplate forward(alias fun)\r\n{\r\n import std.format : format;\r\n import std.traits: Parameters;\r\n enum name = __traits(identifier, fun);\r\n static foreach (ovl; __traits(getOverloads, __traits(parent, fun), name)) {\r\n mixin(q{\r\n @(__traits(getAttributes, fun))\r\n auto ref %s(Parameters!ovl args)\r\n {\r\n return ovl(args);\r\n }\r\n }.format(name));\r\n }\r\n}<\/pre>\n\n
interface JsonSerializable\r\n{\r\n string asJson() const;\r\n}\r\n\r\nvoid main()\r\n{\r\n auto mock = new Mock!JsonSerializable();\r\n}<\/pre>\nclass Mock(alias Interface) : Interface\r\n{\r\n import std.format : format;\r\n import std.traits: Parameters;\r\n static foreach (member; __traits(allMembers, Interface)) {\r\n static foreach (fun; __traits(getOverloads, Interface, member)) {\r\n mixin(q{\r\n @(__traits(getAttributes, fun))\r\n auto ref %s(Parameters!fun args)\r\n {\r\n \/\/ record call\r\n static if (!is(ReturnType!fun == void)) {\r\n return ReturnType!fun.init;\r\n }\r\n }\r\n }.format(member));\r\n }\r\n }\r\n}<\/pre>\nError: function `challenge.Mock!(JsonSerializable).Mock.asJson` return type\r\ninference is not supported if may override base class function<\/pre>\n
auto<\/code> cannot be used here. We have to fall back to explicitly specifying the return type:<\/p>\nclass Mock(alias Interface) : Interface\r\n{\r\n import std.format : format;\r\n import std.traits: Parameters, ReturnType;\r\n static foreach (member; __traits(allMembers, Interface)) {\r\n static foreach (fun; __traits(getOverloads, Interface, member)) {\r\n mixin(q{\r\n @(__traits(getAttributes, fun))\r\n ReturnType!fun %s(Parameters!fun args)\r\n {\r\n \/\/ record call\r\n static if (!is(ReturnType!fun == void)) {\r\n return ReturnType!fun.init;\r\n }\r\n }\r\n }.format(member));\r\n }\r\n }\r\n}<\/pre>\nref<\/code> functions though. What about adding a ref<\/code> in front of the return type, like we did in the first challenge?<\/p>\n\/\/ as before\r\n ref ReturnType!fun %s(Parameters!fun args) ...<\/pre>\n
pure<\/code>, @safe<\/code>, etc.) to match those of the overriden function, but not some others (ref<\/code>, const<\/code>, and the other modifiers).<\/p>\nconst<\/code>, immutable<\/code>, shared<\/code>, and static<\/code>. These are yet another category of function “aspects”.<\/p>\n mixin(q{\r\n @(__traits(getAttributes, fun))\r\n %sReturnType!fun %s(Parameters!fun args)\r\n {\r\n \/\/ record call\r\n static if (!is(ReturnType!fun == void)) {\r\n return ReturnType!fun.init;\r\n }\r\n }\r\n }.format(\r\n (functionAttributes!fun & FunctionAttribute.const_ ? "const " : "")\r\n ~ (functionAttributes!fun & FunctionAttribute.ref_ ? "ref " : "")\r\n ~ ...,\r\n member));\r\n }<\/pre>\nstd.typecons.wrap<\/code>, you will see that part of the code deals with synthesizing bits of a string mixin for the storage classes and modifiers.<\/p>\nThe Ugly<\/h2>\n
openmethods<\/code> library. During the “Perfect forwarding” discussion, it appeared that I was not the only one who wanted to do this.<\/p>\nopenmethods<\/code> here (see an older blog post<\/a> for an overview of the module); for the purpose of this article, it suffices to say that, given a function declaration like this one:<\/p>\nMatrix times(virtual!Matrix a, double b);<\/pre>\n
openmethods<\/code> generates this function:<\/p>\nMatrix dispatcher(Matrix a, double b)\r\n{\r\n return resolve(a)(a, b);\r\n}<\/pre>\nvirtual<\/code> template is a marker; it indicates which parameters should be taken into account (i.e., passed to resolve<\/code>) when picking the appropriate specialization of times<\/code>. Note that only a<\/code> is passed to the resolve<\/code> function—that is because the first parameter uses the virtual!<\/code> marker and the second does not.<\/p>\ndispatcher<\/code> is not allowed to use the type of the parameters directly. Inside the openmethods<\/code> module, there is no Matrix<\/code> type. Thus, when openmethods<\/code> is handed a function declaration, it needs to synthesize a dispatcher<\/code> function that refers to the declaration’s parameter types exclusively via<\/em> the declaration. In other words, it needs to use the ReturnType<\/code> and Parameters<\/code> templates from std.traits<\/code><\/a> to extract the types involved in the declaration – just like we did in the examples above.<\/p>\nReturnType!times dispatcher(\r\n RemoveVirtual!(Parameters!times[0]) a, Parameters!times[1] b)\r\n{\r\n return resolve(a)(a, b);\r\n}\r\n\r\npragma(msg, typeof(&dispatcher)); \/\/ Matrix function(Matrix, double)<\/pre>\nRemoveVirtual<\/code> is a simple template that peels off the virtual!<\/code> marker from the type.<\/p>\n@nogc void scale(ref virtual!Matrix m, lazy double by);\r\n\r\n@nogc ReturnType!scale dispatcher(RemoveVirtual!(Parameters!scale[0]) a, Parameters!scale[1] b)\r\n{\r\n return resolve(a)(a, b);\r\n}\r\n\r\npragma(msg, typeof(&dispatcher)); \/\/ void function(Matrix a, double b)<\/pre>\nref<\/code> on the first parameter and the lazy<\/code> on the second. What happened to them?<\/p>\nParameters<\/code>. This template is a wrapper around an obscure feature of the is<\/code><\/a> operator used in conjunction with the __parameters<\/code> type specialization. And it is quite a strange beast. We used it above to copy the parameter list of a function, as a whole, to another function, and it worked perfectly. The problem is what happens when you try to process the parameters separately. Let’s look at a few examples:<\/p>\npragma(msg, Parameters!scale.stringof); \/\/ (ref virtual!(Matrix), lazy double)\r\npragma(msg, Parameters!scale[0].stringof); \/\/ virtual!(Matrix)\r\npragma(msg, Parameters!scale[1].stringof); \/\/ double<\/pre>\n
pragma(msg, Parameters!scale[0..1].stringof); \/\/ (ref virtual!(Matrix))\r\npragma(msg, Parameters!scale[1..2].stringof); \/\/ (lazy double)<\/pre>\n
scale<\/code>:<\/p>\nReturnType!scale dispatcher(???, Parameters!scale[1..2]) { ... }<\/pre>\n???<\/code>. RemoveVirtual!(Parameters!scale[0..1])<\/code> would not work. RemoveVirtual<\/code> expects a type, and Parameters!scale[1..2]<\/code> is not a type—it is a sort of conglomerate that contains a type, and perhaps storage classes, type constructors, and UDAs.<\/p>\nmixin(q{\r\n %s ReturnType!(scale) dispatcher(\r\n %s RemoveVirtual!(Parameters!(scale)[1]) a,\r\n Parameters!(scale)[1..2] b)\r\n {\r\n resolve(a)(a, b);\r\n }\r\n }.format(\r\n functionAttributes!scale & FunctionAttribute.nogc ? "@nogc " : ""\r\n \/* also handle other function attributes *\/,\r\n __traits(getParameterStorageClasses, scale, 0)));\r\n\r\npragma(msg, typeof(dispatcher)); \/\/ @nogc void(ref double a, lazy double)<\/pre>\nTo Boltly Refract…<\/h3>\n