I tend to use Iterator::inspect() quite heavily and find it extremely useful. Similar combinator would be also very useful for other objects that usually involve long combinator chains. So I decided to experiment with similar functionality for Option and Result. It worked quite nicely, so here it is - inspector. Feedback is welcome.
5 Likes
Brilliant. Sometimes it's the little things 
One thing that might be worth considering, prompted by the comment that it's more usual for this to be used when debugging. Perhaps there could be a variant/version/feature that lets them optimise to a NOP (doesn't call the closure) in release builds.
The futures one is particularly interesting. When it was working, did it invoke the closure every time the future was polled, or when it was resolved?
That's definitely a thing to consider!
The closure is called when the underlying future is resolved with an error.
And here we go! The new drop makes it NOP on release by default, with "inspect-release" feature to override it.
Cool! Bikeshedding: My intuition is that it's probably better to have variant methods, so it's clear what's intented/expected in the code, but either way it's a good capability. I can also imagine many other variants and uses, for different kinds of debugging: sampling that inspects every n'th or with n% probability, inspect that creates dtrace or similar observables, etc etc.
Indeed! Didn't find it when I was looking for something like that. I guess I never tried searching for "tap".