<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay <span dir="ltr"><<a href="mailto:danielmicay@gmail.com" target="_blank">danielmicay@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 21/06/14 07:55 PM, Benjamin Striegel wrote:<br>
>> No one will use Rust if it's slow. If it uses checked arithmetic, it<br>
>> will be slow. There's nothing subjective about that.<br>
><br>
> This is the only argument that matters.<br>
><br>
> If we are slower than C++, Rust will not replace C++ and will have<br>
> failed at its goal of making the world a safer place. The world already<br>
> has a glut of safe and slow languages; if inefficiency were acceptable,<br>
> then C++ would have been replaced long ago.<br>
><br>
> In addition, bringing up hypothetical CPU architectures with support for<br>
> checked arithmetic is not relevant. Rust is a language designed for<br>
> 2014, not for 2024.<br>
><br>
> And if in 2024 we are all suddenly gifted with CPUs where checked<br>
> arithmetic is literally free and if this somehow causes Rust to be<br>
> "obsolete" (which seems unlikely in any case), then so be it. Rust is<br>
> not the last systems programming language that will ever be written.<br>
<br>
</div>Not only does the hardware have to provide it, but each OS also has to<br>
expose it in a way that Rust could use to throw an exception, unless the<br>
proposal is to simply abort on overflow. LLVM would also have to gain<br>
support for unwinding from arithmetic operations, as it can't currently<br>
do that. Even with hardware support for the operation itself, giving<br>
every integer operation a side effect would still cripple performance by<br>
wiping out optimizations.<br></blockquote><div><br></div><div>This is going off on a tangent (and I hope editing the subject will make gmail consider it a separate conversation), but I've been bothered for a while by our apparent lack of distinction between, as I've heard them referred to, recoverable and unrecoverable errors. Unrecoverable errors are programmer errors. Per their name, they are not recoverable. They don't "happen" at runtime, or even compile time, but at program-writing time, and the only way to recover from them is to go back to program-writing time and fix the program. Things like out-of-bounds array accesses, accidental overflow, `assert`s and `debug_assert`s would belong in this category. Meanwhile, recoverable errors are merely problems which occur at runtime, and it should be possible to recover from them.<br>
<br></div><div>Task failure, recoverable from without the task but not within it, is kind of neither here nor there.<br><br></div><div>What if we *did* move to program abort for unrecoverable errors?<br><br></div><div>And what if we did (eventually) grow an actual exception handling system for (some) recoverable errors? We'd enforce the same isolation guarantees for `try { }` blocks as we do for tasks - in other words, a `try` block couldn't share state with the rest of the function - so exception safety would continue to not be a concern. (I know we have `try()`, but it's kind of coarse and has an up-front performance cost.) To me, the hard part doesn't seem to be exception safety, but figuring out what things can be thrown and how they are caught, whether they're part of function signatures or exist outside them, and so on. The catches-based-on-type-of-thrown-object mechanism used by existing languages doesn't appeal to me, but I don't have many better ideas either.<br>
</div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div></div>