[rust-dev] Integer overflow, round -2147483648
jhm456 at gmail.com
Sat Jun 21 17:10:59 PDT 2014
OK. You folks made good points.
How about if I retract "or obsolete" in favor of "or up for big change or
not the tool for those purposes"? Maybe abort-on-overflow in suitable
On Sat, Jun 21, 2014 at 5:02 PM, Daniel Micay <danielmicay at gmail.com> wrote:
> On 21/06/14 07:55 PM, Benjamin Striegel wrote:
> >> No one will use Rust if it's slow. If it uses checked arithmetic, it
> >> will be slow. There's nothing subjective about that.
> > This is the only argument that matters.
> > If we are slower than C++, Rust will not replace C++ and will have
> > failed at its goal of making the world a safer place. The world already
> > has a glut of safe and slow languages; if inefficiency were acceptable,
> > then C++ would have been replaced long ago.
> > 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.
> > And if in 2024 we are all suddenly gifted with CPUs where checked
> > arithmetic is literally free and if this somehow causes Rust to be
> > "obsolete" (which seems unlikely in any case), then so be it. Rust is
> > not the last systems programming language that will ever be written.
> Not only does the hardware have to provide it, but each OS also has to
> expose it in a way that Rust could use to throw an exception, unless the
> proposal is to simply abort on overflow. LLVM would also have to gain
> support for unwinding from arithmetic operations, as it can't currently
> do that. Even with hardware support for the operation itself, giving
> every integer operation a side effect would still cripple performance by
> wiping out optimizations.
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev