Re: opApply and attributes
On Tuesday, 14 July 2020 at 00:17:14 UTC, solidstate1991 wrote: Something like that, but with @safe, pure, etc. attributes. I've tried to "bruteforce" it by generating functions with combinations of attributes, and it kinda works, but is a very janky solution. I'll brainstorm some DIP to fix this issue.
Re: opApply and attributes
On Tuesday, 7 July 2020 at 20:53:05 UTC, Ali Çehreli wrote: I am not sure whether I understand it correctly but there has been a request for opApply() to gain the attributes of the delegate (or the range?). In other words, "transfer the attributes to opApply". This is needed because I want opApply() to work with any foreach body, attributes of which opApply() cannot know. I am sure I created an issue on Dlang bug tracker for Weka on this topic but I can't find it now. (Aside: The search boxes on the bug tracker are inferior to the automatic search feature that works when creating a bug.) Anyway, this one seems related: https://issues.dlang.org/show_bug.cgi?id=7543 Ali Something like that, but with @safe, pure, etc. attributes.
Re: opApply and attributes
On 7/6/20 5:20 PM, solidstate1991 wrote:> See implementation of data
structure here:
>
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565
>
>
> If I try to compile this code, it'll fail, limiting it's usecase:
>
> @safe pure unittest {
> alias IntMap = TreeMap!(int, int, false);
> IntMap test;
> test[5] = 5;
> test[7] = 7;
> test[3] = 3;
> foreach(elem, key; test) {
> assert(elem == key);
> }
> }
I am not sure whether I understand it correctly but there has been a
request for opApply() to gain the attributes of the delegate (or the
range?). In other words, "transfer the attributes to opApply". This is
needed because I want opApply() to work with any foreach body,
attributes of which opApply() cannot know.
I am sure I created an issue on Dlang bug tracker for Weka on this topic
but I can't find it now. (Aside: The search boxes on the bug tracker are
inferior to the automatic search feature that works when creating a
bug.) Anyway, this one seems related:
https://issues.dlang.org/show_bug.cgi?id=7543
Ali
Re: opApply and attributes
On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts
to `scope int delegate(ref E)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Unfortunately this doesn't really work, even with explicitly
defined foreach arguments.
Re: opApply and attributes
On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts
to `scope int delegate(ref E)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Yeah, but unfortunately then this won't work:
foreach(elem; test) {
assert(elem == key);
}
you'd have to spell out the types for `elem`.
Re: opApply and attributes
On Tuesday, 7 July 2020 at 00:20:40 UTC, solidstate1991 wrote:
See implementation of data structure here:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565
If I try to compile this code, it'll fail, limiting it's
usecase:
@safe pure unittest {
alias IntMap = TreeMap!(int, int, false);
IntMap test;
test[5] = 5;
test[7] = 7;
test[3] = 3;
foreach(elem, key; test) {
assert(elem == key);
}
}
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts to
`scope int delegate(ref E)`, this version will accept both @safe
and non-@safe delegates. (And likewise for the other function
attributes.)
opApply and attributes
See implementation of data structure here:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565
If I try to compile this code, it'll fail, limiting it's usecase:
@safe pure unittest {
alias IntMap = TreeMap!(int, int, false);
IntMap test;
test[5] = 5;
test[7] = 7;
test[3] = 3;
foreach(elem, key; test) {
assert(elem == key);
}
}
I know that implementing foreach with other means do exist, and I
used them in my other data structures, but it's much more
difficult (and potentially slower) to implement that within a
binary search tree.
Should I change the `opApply` into the `popfront` - `front` -
`empty` trinity, or write a template that overrides all the
potential attribute combinations?
Maybe D needs a template for attributes somehow, or something
like that.
Re: Using opApply and Attributes
On Sunday, 20 November 2016 at 16:36:18 UTC, Q. Schroll wrote:
How can I have relative-@attrib functions without unnecessary
manual overloading?
import std.traits;
auto f1(DG) (DG dg) if (isCallable!DG && Parameters!DG.length ==
1 && is(Parameters!DG[0] == int)) { // check other things here
too, like return type
return dg(1);
}
void main () pure {
f1((int x) => 2*x); // ok, f1 is pure
//f1(x => 2*x); // alas, now you have to manually specify
argument types
}
not the best solution, of course, and you can't do that without
templates ('cause `nothrow` or `@nogc` *can* require different
machine code in the future).
Using opApply and Attributes
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-@nogc).
How can I have relative-@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
