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

           Summary: opApply should be the first-choice foreach iteration
                    method.
           Product: D
           Version: 2.036
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dsimcha@yahoo.com


--- Comment #0 from David Simcha <dsimcha@yahoo.com> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #1 from David Simcha <dsimcha@yahoo.com> 2009-11-16 06:21:38 PST ---
Forgot to mention:  Also, when using virtual functions, it may sometimes be reasonable to define an opApply as an optimization for foreach loops, even if the range-based foreach has the exact same semantics.  For example:

class Foo {
    SomeType front() {  return _front;}
    void popFront() {
        // do stuff.
    }

    bool empty() {
        return _empty;
    }
}

In this case each iteration will require three virtual function calls, whereas if opApply were used, the overhead would be reduced to a single delegate call.

-- 
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=3514


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #2 from Don <clugdbug@yahoo.com.au> 2009-11-16 06:40:54 PST ---
Doing this will also fix bug 2984 (which is marked as a regression, but isn't
really).

-- 
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=3514


Leandro Lucarella <llucax@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |llucax@gmail.com
         Resolution|                            |DUPLICATE


--- Comment #3 from Leandro Lucarella <llucax@gmail.com> 2009-11-16 12:44:28 PST ---
*** This issue has been marked as a duplicate of issue 2984 ***

-- 
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=3514


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> 2009-11-16 13:07:44 PST ---
This bug supersedes bug 2984, because solving this bug will not only address the problem in 2984, but address a very important problem that is not identified in 2984.  That is:  if opApply is present *at all* it should override any range functionality when sending to foreach.  This includes the case not identified in 2984 in which valid range operations are present *alongside* opApply.  e.g.:

import std.stdio;

struct S
{
    int front()
    {
        return 0;
    }

    bool empty()
    {
        return true;
    }

    void popFront()
    {
    }

    int opApply(int delegate(ref int x) dg)
    {
        writeln("inside opapply");
        int x = 0;
        return dg(x);
    }
}

void main()
{
    S s;
    foreach(i; s)
    {
        writeln("inside loop %d", i);
    }
}

Currently outputs nothing, it should output:
inside opapply
inside loop 0

-- 
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=3514



--- Comment #5 from Leandro Lucarella <llucax@gmail.com> 2009-11-16 13:46:50 PST ---
Then bug 2984 should be marked as a duplicate for this bug, right? There is definitely duplication in this 2 bugs, and there is no point to keep both open.

I won't do it just in case I'm messing it up again ;)

-- 
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=3514



--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> 2009-11-16 14:01:40 PST ---
Yeah, probably :)  I'll do it.

-- 
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=3514


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |2korden@gmail.com


--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2009-11-16 14:04:03 PST ---
*** Issue 2984 has been marked as a duplicate of this issue. ***

-- 
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=3514



--- Comment #8 from Leandro Lucarella <llucax@gmail.com> 2009-12-15 16:52:04 PST ---
http://www.dsource.org/projects/dmd/changeset/295

-- 
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=3514


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #9 from Walter Bright <bugzilla@digitalmars.com> 2009-12-18 21:02:43 PST ---
More discussion:

http://www.digitalmars.com/d/archives/digitalmars/D/opApply_Vs._Ranges_What_should_take_precedence_101124.html

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