On 28/03/14 22:04, 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.
At no point do the compiler writers assume they themselves are
infallible; if they did, the compiler and stdlib could just be written
with unsafe everywhere, to avoid having to satisfy rustc, which can be
annoyingly picky. You'll notice that this is not the case, and reviewers
strongly discourage adding large amounts of `unsafe`, preferring
completely safe code, or, if that's not possible, the unsafety wrapped
into self-contained segments, to make auditing them for correctness
easier. In fact, a large motivation for working on Rust is because the
developers know how fallible they are.
A lot of work has gone, and is going, into making the compiler and
libraries safe and correct. (Of course, getting a completely
verified-correct compiler is really, really hard work, and even the
proof of correctness of the type system is incomplete, but is currently
being worked on.)
In any case, those writing the compiler are likely to be the ones with
the best knowledge of Rust, and, in particular, the best knowledge of
how to write correct unsafe/low-level code: e.g. how to avoid inducing
undefined behaviour, and how to maintain the various invariants that
exist. I think it's reasonable to assume that most other people using
Rust will not have this in depth knowledge. Personally, I would prefer
to put more trust in the experienced users.
(Experience in writing safe Rust code is less relevant here, since,
assuming the proof works smoothly/we adjust the language to make it
work, it will be impossible to write vulnerable code without `unsafe`.)
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.
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.
Rust explicitly gives options too, and definitely does *not* force
bounds checking on everyone: the `unsafe` escape hatch allows someone to
choose to forgo bounds checking when it has a noticeable effect on
performance, and there's no safe substitute (i.e. non-sequential vector
accesses in a tight loop).
Huon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
