Bug 4126 – std.range.ElementType doesn't work with opApply

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; }

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?

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.