Another thought on this. Currently, either the compiler is satisfies that the code is 100% safe, or we slap an "unsafe" keyword around the code and put 100% of the responsibility on the programmer, with no support from the Rust system.
Wouldn't it make sense to have a "not statically safe, but verified at run time" safety as a middle ground? In the context of the "stolen" proposal, when one "steals" a pointer, the original location could be set to null, and only be restored to a non-null pointer when the value is "put back". This means any access to it would cause an exception - which is what one would intuitively expect a hold to behave like. I have a feeling that there is a non-trivial amount of code which is "actually safe" but would impossible to convince the compiler it is "statically safe". Surely having run-time safety in such cases is better than none at all...? On Sat, Aug 31, 2013 at 3:50 AM, Patrick Walton <[email protected]> wrote: > On 8/30/13 3:39 PM, Patrick Walton wrote: > >> Thoughts? Does this seem useful? Are there soundness issues I didn't >> notice? >> > > Brian pointed out a massive soundness hole in this, unfortunately. The > problem is that you can read from the original locations; the right to read > is not "shut off" during the borrow. I think the fix would have to be to > replace this with some sort of "generalized swap" operation. > > > Patrick > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
