On Sat, Feb 9, 2013 at 4:07 PM, Niko Matsakis <[email protected]> wrote:
> > Perhaps. Right now we only track this at the resolution of local > variables, but it would be possible to extend it to something > finer-grained. In this case, though, the value was accessed through an > `&mut`, which means we'd have to be extra careful, particularly around > function calls, as there may be other ways to read the value than what we > can immediately see. The only other ways to read a value pointed to by an &mut that I can think of are through an &const and potentially though an @mut, if you can read from the @mut while there's an &mut into it. If either of these is the case, then the update/replace function wouldn't be safe either, since f could read v.l indirectly after v.l has been moved into f, breaking uniqueness guarantees. The only other thing I can think of is to make moving lazy, such that when you move a value from p to q, p is only deinitialized when q might be used. That way, moving v.l into the ~Cons would be effectively delayed so that it happens simultaneously with moving the ~Cons into v.l.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
