Change:
code. Rust's failure system is not compatible with exception handling in other languages. Unwinding must be caught and handled at FFI boundaries. <ins> [noalias]: http://llvm.org/docs/LangRef.html#noalias </ins> ##### Behaviour not considered unsafe This is a list of behaviour not considered *unsafe* in Rust terms, but that may

Discussion:
As I rub against the boundaries of unsafe and undefined behaviour more and more It's becoming less "obvious" to me what is or isn't allowed. To demonstrate this I've whipped up a few examples of safe and unsafe code that does basically the same thing. Some of them are clearly defined or clearly undefined in my mental model, but I really have no idea at this point. is clearly defined, as it uses no unsafe code. We re-loan a mutable reference to a different variable temporarily. At any given point there's clear ownership of the value. does the exact same thing, but through a instead of an . Ownership is still "clear" to the compiler, but we mutate through the , and then later through the . It wouldn't be unreasonable to consider this undefined behaviour. We mutated something "owned" by an through something other than that , and then worked with the value through the . does the exact same things as , but explicitly constructs an &'static mut to mutate through unsafely. Here we have created two &mut's to the same value, which in my mental mode is clearly invoking undefined behaviour as I understand it. You cannot have two &mut's to the same value. is basically the same as , but we've a box in the way. This adds a rawptr between the and the actual data. Semantically the data is still "owned" by the , but is the in-between important or just an implementation detail? Regardless this is all safe, so this must be defined. is the same as , but we've a again. This time we mutate the data inside the box while the box is owned. However the box is a , so really we've just mutated data behind a rawptr with another rawptr. Now it really matters if the box's representation is defined or not! Critically I believe that the defined-ness of this case effects whether DList is sound or not. It mixes boxes, s, and s pretty freely. What is or isn't allowed is important. Finally is a special case of unsafe mutable aliasing. Here we construct a to a subfield of a composite structure. Then we capture the whole structure with an . We mutate the subfield while the whole struct is owned, but then only use the ownership to mutate a different subfield.

At no point do we read the "unsafely" mutated field. Then we relinquish ownership to the "parent" owner which, presumably, must assume that all fields may have been mutated since it loaned the structure out. Is this defined behaviour? I honestly have no clue.
Nominating, because we need to either specify this for 1.0 or we need to take the Go route and say that all usage of carries no guarantee of BC whatsoever.
The aliasing model is essentially the same as in the C11 memory model, because Rust references the LLVM documentation. If you have an understanding of aliasing, the rules are clear. It is defined based on memory dependencies, not address equality.
I realize that pointer aliasing is not easy to grasp and that the documentation doesn't attempt to teach this, but that doesn't make it a backwards compatibility issue. The just needs to clarify that the scoped noalias model (same as ) applies to and . I think it's a bit much to expect us to document the meaning of aliasing without referencing LLVM at this point, because it's hard to explain it to someone who doesn't grasp it already.
P-high. Would be nice.
Mostly that solves it, but there are still problems with "implicit accesses" (e.g. (f), which may be a problem if for some reason the compiler loads as 2 words, modifies the lower one, then stores both).
CC
CC
Sorry but that really doesn't resolve the issue at hand. In particular it's an issue about how and are allowed to interact.
Can you give me the specific, exact details that you want, then?
This isn't a documentation problem per-se. It's more of a well-defined/concensus problem. I'm fairly certain there is no concensus on exactly what the rules are for what you're allowed to do with a to values that are held by an . was working on some detailed discussion but accidentally deleted it on their last day at Mozilla (and now can't work on it because of their contract at Apple). :( Although perhaps you've managed to obtain some level of concensus?
This was previously described as a doc bug. If it's not, then it's not a big deal to me, at the moment.
is this still unclear today? it's been a while
Abso-lutely.

Nothing has been done in this space, and there's nothing on the horizon that will change this fact.
cc
Closing in favor of