I assume what you're trying to say is that we should allow multiple mutable 
references to pointer-free data. (Note that, as Huon pointed out, this is not 
the same thing as the Copy bound.)

That is potentially plausible, but (a) it adds more complexity to the borrow 
checker; (b) it's a fairly narrow use case, since it'd only be safe for 
pointer-free data; (c) it admits casts like 3u8 -> bool, casts to out-of-range 
enum values, denormal floats, and the like, all of which would have various 
annoying consequences; (d) it complicates or defeats optimizations based on 
pointer aliasing of &mut; (e) it allows uninitialized data to be read, 
introducing undefined behavior into the language. I don't think it's worth it. 

Patrick

On May 31, 2014 4:42:10 PM PDT, Tommi <[email protected]> wrote:
>On 2014-06-01, at 1:02, Patrick Walton <[email protected]> wrote:
>
>>    fn my_transmute<T:Clone,U>(value: T, other: U) -> U {
>>        let mut x = Left(other);
>>        let y = match x {
>>            Left(ref mut y) => y,
>>            Right(_) => fail!()
>>        };
>>        *x = Right(value);
>>        (*y).clone()
>>    }
>
>If `U` implements `Copy`, then I don't see a (memory-safety) issue
>here. And if `U` doesn't implement `Copy`, then it's same situation as
>it was in the earlier example given by Matthieu, where there was an
>assignment to an `Option<Box<str>>` variable while a different
>reference pointing to that variable existed. The compiler shouldn't
>allow that assignment just as in your example the compiler shouldn't
>allow the assignment `x = Right(value);` (after a separate reference
>pointing to the contents of `x` has been created) if `U` is not a
>`Copy` type.
>
>But, like I said in an earlier post, even though I don't see this
>(transmuting a `Copy` type in safe code) as a memory-safety issue, it
>is a code correctness issue. So it's a compromise between preventing
>logic bugs (in safe code) and the convenience of more liberal mutation.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to