[rust-dev] Compiling with no bounds checking for vectors?

Huon Wilson dbau.pp at gmail.com
Fri Mar 28 04:57:13 PDT 2014

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).


More information about the Rust-dev mailing list