> Not sure how this would prevent mutation of keys after they've been placed
> in the hash. Could you please point me to an example?
strcat's example is fine. Basically, when you create an immutable,
borrowed pointer, you also promise to keep that data immutable for the
lifetime of the pointer---and the compiler holds you to it.
> Would it be the same kind of error I am getting in Rust 0.6 if I use owned
> vector instead of a managed one? This code fails to compile even if I'm
> borrowing distinct elements of z:
Yes, same sort of error. The checks do not distinguish between the indices
of the vector. To address this particular case, I think we will eventually
add a variety of methods that take in an `&mut [T]` and allow you to slice
it up in various ways. For example, this would be perfectly sound, although
the implementation would be unsafe:
/// Returns `v[0:index]` and `v[index:]`, to use Python notation
fn split_mut<'a, T>(v: &'a mut [T],
index: uint) -> (&'a mut [T], &'a mut [T]);
This would then be sufficient to implement your example, if awkwardly:
> fn add(x:&mut int, y:&mut int)
> {
> *x = *x + *y;
> }
> pub fn main()
> {
> let mut z = ~[1,2,3];
> { // the block contains the scope of the split
> let (z1, z2) = z.split_mut(1);
> add(&mut z1[0], &mut z2[0]);
> }
> print(fmt!("%d\n", z[0]));
> }
Presumably we'd then make more nice wrappers around `split_mut`
to handle various common cases.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
