On 11-07-13 02:12 PM, Michael Sullivan wrote:
I like this solution because I think it effectively captures a really handy use of blocks without needing add much "magic" or special cases. In particular, I think that making it explicit gives us a good method for forcing the return of a value from an iterator body block whereas I don't think we had a good way to do that when keeping the control flow handling implicit. It also has the advantage that the flow_control value can be inspected and handled in custom ways (perhaps there is some cleanup that needs to be done before returning).
Resources should handle cleanup-before-return and such. But I agree that a way to reify the flow values might well prove valuable to someone building a sufficiently exotic iterator.
My concern is not that your design here is *wrong*, merely too cumbersome to be the common case. I think it's a faithful encoding of what we discussed, and am happy to have seen it written out as such. Nice that you got it running!
I'm curious though if there's a "minimal set of special cases" (in the parser, triggered by the keywords 'for' and 'iter', say) that can capture the most common few idioms with less chatter, retaining the fully reified version as a sort of "under the covers" mode you can access if you've hit the limit of the conveniences. I realize this is a bit of hand-waving but it's the direction I'd like to see it go. Life isn't *that* miserable with 'iter' being its own type; maybe we can permit casts to and from the reified-as-fn form?
I'm quite willing to add special cases "for the sake of iterating". Of course minimalism is always preferable to complexity, but iterating is what computers spend most of their time doing, and one form or another of iterator code makes up great many APIs and libraries.
(You could even view this as a sort of "imperative corollary" for Hughes' observations about the greater compositionality of lazy functions, via the analogy between iterators and infinite data structures..)
-Graydon _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
