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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
