[Issue 5691] walkLength() compatible with opApply()

[d-bugmail at puremagic.com]

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



--- Comment #9 from bearophile_hugs at eml.cc 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: -------