LinkSeq opApply does not expose element index

I've added an opApply function that enables the above use case, hopefully in the same manner as you wanted it to have.

public class LinkSeq(T) : SeqCollection!(T), Sortable!(T) {
        /* .... */
        
	int opApply (int delegate (inout uint index, inout T value) dg) {
		auto scope iterator = new CellIterator!(T)(this);
		return iterator.opApply (dg);
        }
                
        /* .... */

        private static class CellIterator(T) : AbstractIterator!(T) {
                /* .... */

		int opApply (int delegate (inout uint index, inout T value) dg) {
			int result;

			for (auto i=remaining(); i--;)
				{
				auto value = get();
				if ((result = dg(i, value)) != 0)
					break;
				}
			return result;
        	}

                /* .... */
        }

The above feature request could be applied to at least all *Seq containers. Yet, it doesn't seem to be possible to use a templated opApply in order to ensure different types for indices like int, uint, short, ushort, et al. This means, either there are opApply methods added for all basic integer types, or one index type is specified for the use with *Seq collection.

Following code would be appreciated, but doesn't quite work out as wanted:

public class LinkSeq(T) : SeqCollection!(T), Sortable!(T)
{
                /* .... */
		int opApply (U) (int delegate (inout U index, inout T value) dg) {
				auto scope iterator = new CellIterator!(T)(this);
				return iterator.opApply (dg);
		}

                /* ...same applies for LinkSeq.CellIterator */
}

Obviously, this would be the easiest way to add such functionality, yet it won't work out, as the compiler (1.018) complains about a method conflict:

/home/jim/tango/tango/util/collection/LinkSeq.d(148): template tango.util.collection.LinkSeq.LinkSeq!(int).LinkSeq.opApply(U) conflicts with function tango.util.collection.LinkSeq.LinkSeq!(int).LinkSeq.opApply at /home/jim/tango/tango/util/collection/LinkSeq.d(142)

Given the fact that this feature is only useful for sequences, it only applies to ArraySeq?, CircularSeq? and LinkSeq?, as those are the only collections that have 'addressable' (via index) elements, addAt methods so to speak.

Comments appreciated!

Yeah, I guess it is quite limited in scope (3 containers). Perhaps we should add the iterator wrapper to these three?

Replying to kris:

Yeah, I guess it is quite limited in scope (3 containers). Perhaps we should add the iterator wrapper to these three?

It's still in question whether to add one index type, or all integer types available. Though.. I think uint/ushort would be the two that make most sense, as opposed to int, as used in the initial example.

I think Kris's suggestion sounds like the right thing to do. I think one index type is enough, probably uint.

Two index types? NOOOOOOO!

:)

I've just seen that the internal opApply methods index from $ to 0. Does anyone see a problem with this? (It's basically foreach_reverse that way..)