http://d.puremagic.com/issues/show_bug.cgi?id=4126

           Summary: std.range.ElementType doesn't work with opApply
           Product: D
           Version: future
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-04-24 17:34:36 PDT ---
ElementType doesn't work with a class/struct that defines an opApply, this
prints 'void' (dmd 2.043):


import std.stdio: writeln;
import std.range: ElementType;

struct Foo {
    char stop;
    int opApply(int delegate(ref long) dg) {
        int result;
        for (long i = 0; i < stop; i++) {
            result = dg(i);
            if (result)
                break;
        }
        return result;
    }
}

void main() {
    writeln(typeid(ElementType!Foo)); // Output: void
}



A naive way to find the type given by the opApply:

template IterType(alias iterable) {
    alias ReturnType!({ foreach(x; iterable)
                            return x;
                        assert(0);
                      }) IterType;
}


A more refined way (this template is named BaseType1, because it goes down just
one level):

...
static if ( is(typeof(T.opApply)) )
        alias OpApplyType!(T) BaseType1;
...


Where:

template OpApplyType(T) {
    static if (ParameterTypeTuple!(ParameterTypeTuple!(T.opApply)[0]).length ==
1)
        alias ParameterTypeTuple!(ParameterTypeTuple!(T.opApply)[0])[0]
OpApplyType;
    else
        alias ParameterTypeTuple!(ParameterTypeTuple!(T.opApply)[0])
OpApplyType;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4126


David Simcha <dsimcha@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha@yahoo.com


--- Comment #1 from David Simcha <dsimcha@yahoo.com> 2010-08-15 08:26:10 PDT ---
A big issue I see here is, what if both opApply and the range interface are defined?  Which should take precedence, or should it be an error?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4126


David Simcha <dsimcha@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #2 from David Simcha <dsimcha@yahoo.com> 2010-08-18 18:00:10 PDT ---
I've added ForeachType to std.traits. (http://dsource.org/projects/phobos/changeset/1897)  I think this is a better solution.  The only thing opApply and ranges have in common is the ability to be iterated over using a foreach loop.  In some corner cases, such as when a class/struct defines both opApply and range primitives, or when the type is a narrow string, ElementType can be different from ForeachType.  If you want your code to be agnostic of how the foreach loop is implemented and simply iterate over the object with a foreach loop, then what you really care about is the ForeachType, not the ElementType.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------