D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 4126 - std.range.ElementType doesn't work with opApply
Summary: std.range.ElementType doesn't work with opApply
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: All All
: P2 enhancement
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-24 17:34 UTC by bearophile_hugs
Modified: 2015-06-09 05:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description bearophile_hugs 2010-04-24 17:34:36 UTC
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;
}
Comment 1 David Simcha 2010-08-15 08:26:10 UTC
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?
Comment 2 David Simcha 2010-08-18 18:00:10 UTC
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.