On 21/06/14 08:16 PM, Tony Arcieri wrote: > On Sat, Jun 21, 2014 at 4:55 PM, Benjamin Striegel > <[email protected] <mailto:[email protected]>> wrote: > > In addition, bringing up hypothetical CPU architectures with support > for checked arithmetic is not relevant. Rust is a language designed > for 2014, not for 2024. > > > So why not do the safe thing by default (which future CPUs may make > fast), and provide a secondary mechanism to get the "unsafe" fast path?
CPU support for trapping on overflow will not make it fast. Either way, it makes every integer arithmetic operation impure and will wipe out many optimizations. The claim that a CPU can make this faster is conjecture until someone explains how we can actually leverage it. Turning trapping on overflow into unwinding on overflow is not a trivial issue and would involve changes to LLVM's design along with potentially non-portable platform support for handling the trapping via a signal handler and then throwing an asynchronous exception.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
