[rust-dev] sub-grammar for range pattern constants?
vadimcn at gmail.com
Tue Apr 30 14:51:40 PDT 2013
- Does "immutable" mean that the referenced object cannot change forever,
even after current function has returned?
Is it possible in Rust to create a hash that stores its' keys by borrowed
reference (assuming that the hash does not outlive contained keys) and be
assured that the keys will not get changed after having been added to the
- Can Rust actually guarantee that &mut are not aliased, - in the face of
all indirection that may happen in a typical program? For example, the
following program compiles and runs without any errors, but, obviously, x
and y are aliased:
fn add(x:&mut int, y:&mut int)
*x = *x + *y;
pub fn main()
let z = @mut [1,2,3];
add(&mut z, &mut z);
On Tue, Apr 30, 2013 at 11:49 AM, Niko Matsakis <niko at alum.mit.edu> wrote:
> Keep in mind that Rust's type system offers very strong guarantees
> about aliasing which I think will be very helpful for this sort of
> optimization. For example:
> - `&T` data is *immutable* (not const)
> - all `&mut` are disjoint (i.e., ANSI C's `restrict`, but checked and
> by default)
> - when an `@mut` is modified, there can be no aliases at that time
> - maybe more?
> The presence of unsafe code does complicate matters. One important
> guideline will be to establish what invariants unsafe code must
> maintain to avoid straying into "undefined behavior" land.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev