http://d.puremagic.com/issues/show_bug.cgi?id=5691
--- Comment #9 from [email protected] 2011-03-03 16:54:17 PST --- (In reply to comment #7) > Instead you may want to use the range interface and benefit of walkLength and > others. The semantics of opApply() is inverted compared to the range interface (the opApply() is similar to the Python yield, with a worse syntax). There are situations where for my mind the semantics of opApply()/yield turns out to be more natural. Example: I'm able to write a tree visit in moments using yield, but it takes me some reflection to perform it with the range interface. Maybe it's just a limit/problem of my mind. In bug 5660 I have also tried to explain that sometimes it's also a compact way to write iterable things. > The worse > problem is that it creates a precedent - then why not do the same for other > algorithms (including find itself of which you complain already)? I see. For me there's a difference between things like map/filter and array/walkLength because a map over a opApply() can't produce a range (efficiently), so I have not seriously asked map() to accept an Iter struct like that. On the other hand array/walkLength don't need to spit out an iterable, they just scan it, so in my mind they are allowed to be able to digest any kind of iterable. So is it right for find() to work on opApply()? I'd like the answer to be positive, but I am willing to accept a negative answer. I'm trying to help, but I leave you the final word on Phobos, and you often know better. Feel free to close this bug report when you have decided. Sorry for my philosophic dilemmas :) > Please abide to your own standards. My standards are complex, because reality is complex. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
