digitalmars.D.bugs - [Issue 3514] New: opApply should be the first-choice foreach iteration method.
- d-bugmail puremagic.com (43/43) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (19/19) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (11/11) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (12/12) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (48/48) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (8/8) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (6/6) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (10/10) Nov 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (6/6) Dec 15 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (11/11) Dec 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
- d-bugmail puremagic.com (11/11) Dec 31 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3514
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 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au 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: -------
Nov 16 2009
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 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Steven Schveighoffer <schveiguy yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |2korden gmail.com 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: -------
Nov 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 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: -------
Dec 15 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 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: -------
Dec 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED 11:20:21 PST --- Fixed dmd 2.038 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 31 2009