On Thu, Jun 6, 2013 at 7:00 PM, Graydon Hoare <[email protected]> wrote:
> On 06/06/2013 8:59 AM, Gábor Lehel wrote: > > Am I way off base with this? An embarrassing misconception? To summarize >> my train of thought >> >> * Catchable exceptions can be implemented >> * But we don't want to, because it would force everyone to think about >> exception safety >> * That could however be avoided with appropriate restrictions >> * Rust's type system already gives us the tools to impose those >> restrictions, as evidenced by them being imposed on `try()` >> * Therefore it should be possible to have much of the benefit of >> catchable exceptions, without their drawbacks >> > > No. The train of thought is that they _already are_ implemented to this > level -- via task isolation[1] -- and people asking for "catchable > exceptions" are (so far) actually asking for us to lift those > restrictions[2], which we don't want to do. > > -Graydon > > [1] If it helps avoid wincing about the implied "cost of spawning a task" > (allocating a segment, switching to it, and switching back on return) it > might help to know that there are some serious discussions going on in the > background about cactus stacks and the requisite scheduler hooks required > to support cilk-like fork/join parallelism. > Oh, okay. I wasn't aware of this sorry. What I knew was that a couple of times, when I raised the possibility of relying on `try()` for error handling, the response was that it wasn't fast enough and possibly never would be (and in one instance the idea of catchable exceptions was floated in response, suggesting that those *would* be fast enough), which is why I thought maybe it would be better (despite costlier) to give in and have a dedicated language feature, instead of only a library solution that's too slow for actual use. But obviously satisfying all the relevant use cases using only existing features is the best possible scenario! > > [2] And/or asking to add "first class" language support for the idioms in > the form of new keywords, RTTI or additional control structures. In case > this is not obvious: we are trying to move as much as possible these days > _out_ of the core language and into libraries and macros. This usually > results in faster iteration, less fragility, fewer personnel and > development/integration bottlenecks, and overall better implementations. > > -- Your ship was destroyed in a monadic eruption.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
