On 28/03/14 07:04 AM, Lee Braiden wrote: > On 28/03/14 03:48, Daniel Micay 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. > > Actually, I believe it does, with this policy. The "infallible > programmer" it imagines, however, is not the developer; true. It is > worse: this policy currently assumes that the policy makers / compiler > creators themselves are infallible; that language users (even language > users of the future, who may have much more knowledge and experience > than anyone participating in this discussion today) are idiots who don't > know what they're doing, or at least, will never know more than the > language creators. This is NOT trusting the tireless work of a > compiler: it's being arrogant, and trusting yourself more than others, > whose abilities and circumstances you do not even know.
Rust provides unchecked indexing. The compiler/library developers have to use `unsafe {}` in order to make use of it too. They're not held to a different standard. You may not be aware that Rust is written in Rust, but it's written in over 200k lines of it. The Rust developers are by far the most prolific users of the language, and are very aware of what it's like to write code in the language. I certainly do not see myself as an idiot, if that's what you're trying to imply. In fact I think I'm quite clever. However, I'm definitely not capable of writing bug-free code all the time. You can call us arrogant or question our motives, but true arrogance is thinking that you can write bug-free code at a non-trivial scale. The Rust developers strive to keep the amount of `unsafe` code at a minimum and only use it when it's proven to result in tangible performance wins. This is also how things are done in Servo, and it is intended to be how the language is used. That's why it puts so much work into drawing safety boundaries. Rust is designed first and foremost as a memory safe language, and that's not going to change. Safety is why most of Rust's type exists, and Rust programmers are free to use `unsafe` as often as they feel is necessary to subvert the type system when they know better. You have every freedom to fork the language if you want to take it in a different direction. > Worse: it is failing to learn from history. The very reason that C / > C++ succeeded is that they don't force things on developers: they > assist, give options. They choose defaults, yes, and make things > easier, yes; but they always provide the option to move out of the way, > when it turns out that those defaults are actually making things > harder. The very reason that many other languages fail is that they > failed to provide the ability to adapt to changing needs. The 'default' (via []) is checked indexing, and unchecked indexing is available. In C++, the default is unchecked indexing (via []) and checked indexing is available on std::array and std::vector via `at`. There's no switch to flip what [] does for those types. There's no configuration of the default in C or C++ - that's nonsense. Rust provides `unsafe` for when you need the compiler to get out of the way. Claiming that the option is not provided is an outright falsehood. > Forcing bounds checking on everyone is really not that different from > forcing garbage collection on everyone: it may seem like a good idea to > some --- even many --- but to others, it is overly limiting. It's not forced on you. You are free to use the unchecked indexing whenever you think it is appropriate. It's not about whether it is a good idea or a bad idea - in some cases, bounds checking is *necessary* and in others you can prove to yourself that it is not necessary. In those cases where it is not necessary, Rust allows you to avoid bounds checking. You are free to do *all* of your indexing via unchecked indexing if you trust yourself (and anyone else who will touch the code) to write bug-free code all the time. In fact, why not use C++? You're not going to want sum types if you can just use unions without the dirty compiler getting in your way. You're not going to want checked type bounds on generics - type classes are clearly just arrogance on the part of developers, users can be expected to read the requirements of a generic function and never write code generating errors from the implementation details. Lifetimes serve no purpose other than to prevent the programmer from doing stuff, and are *entirely* stripped out before code generation. Do you want to override/disable borrow checking and freezing too? There's also the exhaustiveness check in match and let expressions. There's the imperfect flow control analysis used to guarantee that there's a return before the end of a function. There's a dynamic check on integer division for a zero divisor, and INT_MIN / -1 needs to be checked for too with signed integer division. There's the dynamic borrow checking performed on RefCell, which has to be used if you want mutability combined with shared ownership of a non-plain old data type in Rc<T>. You'll be happy to know that Rust already allows working around *all* of these things via `unsafe`. That's right - you can already opt-out of any of these type checking features on a case-by-case basis when you can prove that doing so is correct. You are free to convert between the memory representation of arbitrary types or whatever else you want. Rust just isn't going to pretend that doing so is safe when it can't prove it. > There seem to be a few people saying that providing an option to disable > boundary checks would constitute an ABI change. If so, that's fine: > maybe it makes it more trouble than it's worth to do. Maybe that's > scary. OR, maybe the fact that it requires an ABI change is an > indication of a deeper design flaw. Maybe that's even scarier. But, > one way or another, these knee-jerk reactions to a simple request to > disable a feature do smack of fear. I would suggest that people face > that fear, and acknowledge the real problem, rather than telling people > they shouldn't be asking for the freedom to build a program as they see > fit. These aren't "knee-jerk reactions" and have nothing to do with "fear". You have the freedom to use `unsafe` code in Rust, the freedom to fork the language, and even the freedom to continue using C++ as that's clearly what you want. The Rust developers do not currently plan on staging a worldwide coup in order to take away your C++ compilers and destroy your freedoms. It would introduce a new incompatible language without support for safety boundaries and where correct existing code will need to be rewritten - it certainly can't use the standard library. If you make indexing unsafe without making it considered unsafe for type-checking, then you've removed all of the meaning from `unsafe`. That's a whole new dialect of the language that needs to be considered in all of the code in the standard library. It means doubling the number of buildbots in order to test that everything still passes when using a different language. Rust considers an out-of-bounds error to be a runtime error, and throws a failure. Once you've read a bit of the Rust tutorials, you'll see that failure can be caught - that means programs can be correct in the face on bounds checking errors, as they may simply be happy with handling failures caused by any dynamically invalid conditions. The checks can't simply be disable without changing the semantics of the language.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev