On 13-04-28 03:03 PM, Robert O'Callahan wrote: > I don't understand the relationship between those features and integer > overflow checking. There are very strong reasons why those features > haven't developed, and none of those reasons apply to integer overflow > checking.
Sure. It costs performance. That's the reason in all such cases. It sucks and I'm sad about it and _that argument in those words_ is what I hear over and over from our target audience. Anything that costs performance in the default case is resisted strenuously. > Based on that data and previous experience with this code, I'm certain > that those occurrences are vastly outweighed by handwritten code that > tries to detect/avoid integer overflows, and also by arithmetic > operations that are still vulnerable to overflow bugs in spite of those > checks. For the most part, nobody checks. They weighed the cost of those errors against the potential performance loss and decided they would prefer to go fast. I'm very sad that people in this space are so quick to trade correctness for speed. But they do. And they pick languages (in this space) based on perception of speed. From benchmarks and informal experiments. > So I contend that integer overflow checking is more likely to prevent > unexpected behavior than to cause it, especially when it really matters: > in shipped code that's being attacked. Once in a while someone writing a > hash function or similar will trip over, but it will be easy for them to > detect and correct their mistake. We're not disagreeing on that. > Was this some unsafe-language benchmark shootout? Even if those are > important due to some "Rust is slow, clinical tests prove it" bogo-PR > effect, I assume you would disable overflow checking along with > array-bounds checks in unsafe Rust code. Yes. I'm not sure how else to put this: we're in an unfair fight. We're trying to ship a language that is safer than C++ but is _being benchmarked against C++_. And in a market that generally picks "whatever's fastest". Picking defaults that make us systematically slower than C++ is problematic. Since the speed is not before us in quantified terms, though, I suggest deferring this for a bit: we can implement the feature as a check, and set the flag to default allow, warn, deny, or forbid based on the results of performance measurements. If it's trivially cheap, by all means turn it on by default. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
