I'd like to point out that I agree with your central premise that most bounds checks are useless. Some huge percentage of them, in fact.
But I still enjoy the peace of mind that they bring. If I actually need a piece of code to be manually checked, covered in tests, and benchmarked to be fast, I'll do that. Then I'll switch to unsafe accesses in my hot paths. I'm not sure I'm comfortable with people just arbitrarily switching off bounds checking to exchange an unnoticeable 3% (ballpark) performance increase for unknown security attack vectors. For example, do you really want your entire application to be at risk just because you didn't want bounds checking in some logging code that's never touch in your fast-paths? That just seems silly to me. - Clark On Thu, Mar 27, 2014 at 11:48 PM, Daniel Micay <[email protected]>wrote: > On 27/03/14 11:04 PM, Tommi Tissari wrote: > > Case by case is all fine and good. But you're trying argue what a > programmer *should* do if he knew what was good for him. > > Rust doesn't view the programmer as an infallible, trusted entity. This > is clear in the design of lifetimes. For example, consider this generic > function: > > fn foo<'a, T>(x: &'a [T]) -> &'a T { ... } > > The compiler substitutes in the type parameter `T` and generates a > specialized function. However, lifetimes are simply erased after > type-checking - they can simply become 'static without any changes to > the compiled code. > > > While I'm trying to argue that the programmer should be *free* to test > how fast his code would run without bounds checking, just for the hell of > it. You want to enforce best practices while I want to allow freedom to > choose. > > It's not simply a best practice. It's part of Rust's safety contract, > which is a fundamental part of the language. It influences most aspects > of the language's design. > > > I don't know about those other dialects. > > You're proposing introducing new dialect of Rust. > > In Crust, code generating a failure on out-of-bounds will now cause > silent memory corruption. Crust will do away with safety boundaries > completely by making `unsafe` and lifetimes a no-op in order to be a > true superset of Rust. > > In Frust, indexing slices is considered an unsafe operation. Very little > existing Rust code will compile under Frust, and some previously safe > checked indexing inside existing `unsafe` blocks will cause silent > memory corruption. > > I'm not sure which of these dialects you're proposing, but either one > would require a new set of buildbots to run the tests again. Both the > Crust and Frust languages would require many changes to the > documentation and code of the Rust libraries too. > > You're free to fork the language if you want to fundamentally change the > basic semantics of the language. I hope it's clear why this isn't going > to be acceptable upstream. > > > In D, if you put the label safe in the beginning of each module and > compile it with safe flag (and not with noboundscheck flag), then it is > memory safe barring compiler bugs. It doesn't allow you to use pointer > arithmetic or unsafe casts or call unsafe functions, but that's hardly what > I'd call a *crippled* subset of the language. > > D doesn't even let you use ranges (iterators) in safe code. There are > barely any safe functions here, and that's true of most of the standard > library: > > http://dlang.org/phobos/std_range.html > > > But the point was that D has a memory safe subset and a noboundscheck > flag which obviously makes the compilation *not* memory safe. And I was > wondering why can't rust have this flag too. > > Rust is a memory safe language with a crippled unsafe subset. D is an > unsafe language with a crippled safe subset. Something that may make > sense in the language design for D does not necessarily make sense in > Rust. If you want D, then please go ahead and use D. > > In Rust, bounds check failures are not currently viewed as a logic > error. They are a normal runtime failure that can be handled at a task > boundary. You're going to need to convince us to consider them a logic > error *before* you bring the option of a subset of Rust without logic > error checks to the table. The standard library (and others) currently > rely on this being a failure to guarantee safety elsewhere. Take away > this check and there is no safety even in code without array indexing. > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
