www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4126] New: std.range.ElementType doesn't work with opApply

reply d-bugmail puremagic.com writes:
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



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: -------
Apr 24 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4126


David Simcha <dsimcha yahoo.com> changed:

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



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: -------
Aug 15 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4126


David Simcha <dsimcha yahoo.com> changed:

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



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: -------
Aug 18 2010