On 20/10/2012 5:31 AM, Matthieu Monrocq wrote: > I just realized I had missed a point, which is somewhat similar to what > Gareth raised: composability.
Yeah. None of them have _great_ composability but it's actually the main thing pressing me towards #3. There are composition hazards in #1 and #2, #1 especially; #3 is the most robust, compositionally, even as it requires a bit more indenting. IME multi-condition handling and handling-within-handler cases are *comparatively* rare, not the end of the world if they read a bit worse than simple 1-handler cases (you can always factor body or handler parts out into helper functions); I'm more concerned that the composition is _safe_, and doesn't have confusing or surprising semantics. > Is there any plan to have this available in this Condition/Signal scheme > ? Ie, being able in a condition to defer the decision to the previous > handler that was setup for the very same condition ? Yes. The first version I sketched had this, then I took it out (out of curiosity to see if chaining via the guards also worked) but I'm intending to put it back in once the API-variant is chosen. > I even wonder if this could not become "automatic", that is unless a > handler "fails" hard or returns a proper value, its "predecessor" is > automatically called. However I failed to see how this could be nicely > integrated in the syntax and wonder what the ratio of > "pass-up-the-chain" vs "ignore-predecessors" would be in practice. A handler is just a function. Functions always either return (a "proper value", even if it's ()) or diverge (exit, fail, iloop). There's no 3rd case like "not returning a value" in which to put this as automatic behavior. But we can readily provide API points to handle re-raising (or just make the meaning of .raise called from a handler act this way). -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
