Using opApply and Attributes
Q. Schroll via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Nov 20 08:36:18 PST 2016
When using functions with delegate (or function ptr) parameters
which should comply with some attributes, I cannot call the
delegate in the function what makes it pretty useless (I haven't
done research, but I claim that generally most functions taking
delegate parameters call them).
void f1(void delegate(int) dg) // cannot be pure ...
{
dg(1); // ... due to this call.
}
void main() pure
{
f(x => 2*x); // Error, f is impure.
}
One has to overload the function like
auto f(delegate(Arg arg) @attrib dg) @attrib;
auto f(delegate(Arg arg) dg);
for each combination of attributes available (today 4, worst case
is 16 overloads), could be more in the future.
Even worse (due to bug 15859, see [1]) overload resolution on
opApply does not work properly. Making opApply a template is a
real solution for various reasons (virtual functions, no type
inference on the delegate, etc.). For opApply, using the range
interface (empty, front, popFront) is not a real solutions either
because opApply can be truly recursive. Those can then only have
a range interface through generators via fibers which have an
overhead (and make them non- at nogc).
How can I have relative- at attrib functions without unnecessary
manual overloading?
(relative: if all called parameter delegates have it, then the
function has it)
Generally, are relative attributes worth an enhancement?
[1] https://issues.dlang.org/show_bug.cgi?id=15859
More information about the Digitalmars-d-learn
mailing list