In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it easier... or so on...
What about:
- Defining "safe" integer in Rust with strict and well defined rules.
- Enforcing the rules is an incremental process.
At first, Rust will not enforce any rules, maybe in debug mode or what
not for who wants to pay the cost. One could add an attribute on
blocks to enforce runtime overflow check at all cost, when you really,
really need safety no matter the speed tradeoff. And in the future,
the compiler & standard library are free to effectively enforce more
of the rules, as performances tradeoff mitigate.
Its kinda like when C/C++ compiler started warning that not all cases
where handled in switch/cases on enums (yes I know our case is
different on many level).
What is important, is that the rules of the different safe integer
types are well defined, even if not necessarily enforced yet.
If you think about it, its better than nothing.
The goal is not to solve everything right now, but at least to define
the scope of the problem when it is still possible, before everybody
uses "unsafe integers", so it can be implemented in the future.
On Mon, Jun 23, 2014 at 7:52 PM, Benjamin Striegel
<ben.strie...@gmail.com> wrote:
>> the fact is that everyone is an optimist when it comes to integer overflow
>> bugs. People just do not think they're going to get bitten.
>
> I agree, and I don't think anyone else here is going to try to argue that
> this doesn't cause real bugs. As so often seems to be the case, language
> design amounts to deciding which unfortunate tradeoffs you are willing to
> live with.
>
>
> On Mon, Jun 23, 2014 at 8:16 PM, John Regehr <reg...@cs.utah.edu> wrote:
>>>
>>> I do think Rust should exposed either `checked { }` or operators for
>>> checked arithmetic along with an opt-in lint to deny the unchecked
>>> operators. You can opt-out of a lint for a function/impl/module after
>>> opting into it at a higher scope.
>>>
>>> I'm just making it clear that doing this by default would make Rust
>>> slower than Java by default, and I think that would kill off interest in
>>> the language. I know I wouldn't be interested anymore.
>>
>>
>> Sure, I think there are a lot of reasonable options here, and I agree that
>> speed and predictability are super important for Rust.
>>
>> One thing I personally think is very important (not for 1.0, but
>> eventually) is to make it possible -- no need for this to be mandatory -- to
>> get overflow checking for the default integer type. I'm happy to use a
>> special compiler flag or whatever to get this. The only controversial thing
>> this requires from the core language is a way for me to tell the compiler
>> which integers (a tiny subset, typically) should have wrapping behavior.
>>
>> I realize that safe integers are available and that operator overloading
>> goes a lot ways towards making these palatable, but the fact is that
>> everyone is an optimist when it comes to integer overflow bugs. People just
>> do not think they're going to get bitten.
>>
>> Finally, I'll note that certain optimizations such as array bounds check
>> removal and some loop optimziations actually get better then integers cannot
>> wrap. Clearly we would not expect, in general, for these benefits to make
>> up for the costs of overflow checking.
>>
>>
>> John
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
