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
