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.

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.)

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`.

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.

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

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.

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.