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