Thanks for your response Niko. A couple more questions if you don't mind:
On Wed, May 1, 2013 at 10:51 AM, Niko Matsakis <[email protected]> wrote:
> Hello,
>
> Unfortunately, I accidentally deleted a message from Vadim that I
> wanted to reply to. However, it had strayed from the topic of the
> thread anyhow (which was called "sub-grammar for range pattern
> constants") so I'll just startup a new thread here.
>
> Vadim wrote:
>
> > - Does "immutable" mean that the referenced object cannot change
> > forever, even after current function has returned?
>
> It means that the referenced object cannot change for the lifetime
> of that reference.
>
> > 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 hash?
>
> That would be possible, but the hash would have to be parameterized by
> the lifetime of the keys. What we typically do instead is to have the
> hash own the keys.
>
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?
I agree that owning keys would simplify everything, but on more than one
occasion I've had to index existing large objects to speed-up some lookup
operation. For example, let's say you need to de-dupe a vector of
objects. In C++, I'd just create a hash_set of pointers to objects, but
in Rust those would have to be borrowed references, right? (assuming I
don't want to resort to using raw pointers)
> - Can Rust actually guarantee that &mut are not aliased, - in the
> > face of all indirection that may happen in a typical program?
>
> Yes. That is the job of the borrow checker, and the soundness of the
> Rust type system depends on it. If you do not make use of managed data
> (i.e., no `@`), this guarantee is static. Otherwise the guarantee is
> enforced dynamically.
>
> The example program you gave is not supposed to execute without error;
> the reason that it does is due to bugs. I am about to land (next day
> or so) a branch fixing a number of such bugs. When I run that program
> on my branch, I get a compilation failure. This is because, even
> though you are using `@`, the compiler can clearly see that the
> dynamic check would fail, and so it flags the error statically. If you
> modify the program slightly you can evade this static check, but an
> error should still occur dynamically. Currently it does not (even on
> my branch), this is issue #5910.
>
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:
fn add(x:&mut int, y:&mut int)
{
*x = *x + *y;
}
pub fn main()
{
let mut z = ~[1,2,3];
add(&mut z[0], &mut z[1]);
print(fmt!("%d\n", z[0]));
}
So this sort of code will not be possible? (again, without raw pointers)
Vadim
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
