Bug 3125 – statement foreach semantic opApply should be tried if range funcs not satisfied

Status
RESOLVED
Resolution
WORKSFORME
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Windows
Creation time
2009-07-02T01:09:00Z
Last change time
2015-06-09T01:27:45Z
Assigned to
nobody
Creator
davidl
Blocks
2267

Comments

Comment #0 by davidl — 2009-07-02T01:09:08Z
in ForeachStatement::semantic should be: Dsymbol *shead = search_function(ad, idhead); if (!shead || !search_function(ad, idnext) || !search_function(ad, Id::Fempty) ) goto Lapply; only try to apply range semantic when all prerequisite func available. This makes easier to port legacy code to d2. People won't try to figure why it tries to call the func called empty/next which doesn't provided in my aggregate however the func named head had been accidentally added. This could block tango CircularList
Comment #1 by davidl — 2009-07-02T01:19:48Z
why not create something like IUnknown? e.g. IRange all classes inherited from IRange get the tag of being a range class. This is less hackish of testting funcs. IRange can enforces users to provide those funcs. If there're some problems for optimization, IRange can still be an empty interface for hinting the compiler or treated specially.
Comment #2 by dfj1esp02 — 2009-07-02T01:55:05Z
There was a discussion on introducing concepts to D.
Comment #3 by bugzilla — 2009-07-02T17:47:19Z
I need an example, please, as I can't reproduce the problem.
Comment #4 by davidl — 2009-07-02T19:52:44Z
Here it is: class c { int head() { return 0; } int opApply(int delegate(ref int x) dg) { int i; i=3; dg(i); return 1; } } void main() { c c; c= new c; foreach(m;c) { assert(m==3); } }
Comment #5 by jarrett.billingsley — 2009-07-02T20:37:27Z
(In reply to comment #4) > Here it is: > > class c > { > int head() > { > return 0; > } > int opApply(int delegate(ref int x) dg) > { > int i; > i=3; > dg(i); > return 1; > } > } > > void main() > { > c c; > c= new c; > foreach(m;c) > { > assert(m==3); > } > } You fail it. The error from this code is not related to the reported bug at all. The lines > c c; > c= new c; are illegal. If you change it to > c c = new c; it works fine in 2.029.
Comment #6 by bugzilla — 2009-07-03T00:55:17Z
I'll close this for now as "WORKSFORME". Please reopen if there's a reproducible test case.
Comment #7 by 2korden — 2009-07-03T01:29:00Z
Perhaps, it is a duplicate of issue 2984