Summary: opApply should be the first-choice foreach iteration
           Product: D
           Version: 2.036
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD

--- Comment #0 from David Simcha <> 2009-11-16 06:18:55 PST ---
struct Foo {
    uint front() {
        return 1;

    int opApply(int delegate(ref uint) dg) {
        return 1;

void main() {
    Foo foo;
    foreach(elem; foo) {}

test8.d(68): Error: no property 'empty' for type 'Foo'
test8.d(68): Error: no property 'popFront' for type 'Foo'

Clearly, DMD saw that front() was present and tried to use range foreach.  This
is incorrect because:

1.  Only part of the range interface existed.  The opApply interface was
complete and should have worked.

2.  If someone defines both a range interface and an opApply interface with the
same types, they probably have a good reason, since ranges serve other
purposes, but opApply exists **only** for foreach.

3.  Some things, like iterating over trees, can be done more efficiently with
control of the stack than without.

Also, once opSlice becomes able to define implicit conversions to ranges for
foreach loops, any opApply's defined should take precedence over this for the
reasons mentioned above.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to