doc: Add another 'rule of ownership' to the guide

[nham]

Inspired by this question on Stack Overflow. I feel like maybe there is an ownership rule missing, in section 18.2, which would describe why you cannot do this:

fn main() {
    let mut x = 5i;
    let y = &x; 
    x = 6i; // error: cannot assign to `x` because it is borrowed
}

There is an example which shows this error in the closure section, but it actually has nothing to do with closures and is more about a general principle of "the owner can't mutate what it owns while it has been borrowed"

[lilyball]

This doesn't quite match the phrasing used by the previous 2 restrictions. Also, I think the restriction list is constructed awkwardly to begin with. Bullet 4 is a restriction just on mutably-lent resources, but bullet 5 and the new bullet 6 are restrictions when the resource is lent both mutable and immutably. I would suggest rephrasing this whole thing as follows:

Being an owner gives you three privileges:

1. You control when that resource is deallocated.
2. You may lend that resource, immutably, to as many borrowers as you'd like.
3. You may lend that resource, mutably, to a single borrower.

But it also comes with three restrictions:

1. You may not lend that resource, mutably, if you're currently lending it to someone (either mutably or immutably).
2. You may not lend that resource, immutably, if you're currently mutably lending it to someone.
3. You may not mutate that resource if you're currently lending it to someone.

[lilyball]

Upon further reflection, even this isn't sufficient. You may also not read the resource if it's mutably lent. This includes taking a copy of it, for Copy types. The following program is illegal, despite not actually be covered under the rules as listed:

pub fn main() {
    let mut x = 5i;
    let y = &mut x;
    let z = x;
}

Perhaps the following set of restrictions is better:

1. If that resource is immutably lent to someone, you may not mutate it or mutably lend it to anyone until the original loan expires.
2. If that resource is mutably lent to someone, you may not access the resource in any fashion until the loan expires.

[Gankra]

Oh, this is nice. I'm not sure about using commas to emphasize mutably/immutably, it reads awkwardly to me. However the general form is good.

(also "you'r" -> "you're" in restriction 2.)

[lilyball]

For the original restriction list that you responded to, how about

1. You may not mutably lend that resource if you're currently lending it to someone (either mutably or immutably).
2. You may not immutably lend that resource if you're currently mutably lending it to someone.

Although I think the second comment I made is the better approach.

(typo fixed)

[Gankra]

Augh, github commenting race conditions. Was commenting on the first comment, in case it wasn't clear. (edit: kballard plz stop sniping me ;_; )

I might clarify your new point 2 as:

If that resource is mutably lent to someone, you may not loan or access the resource in any fashion until the mutable loan expires.

(Because whether a loan is an access is ambiguous to me)

[nham]

@kballard I've adopted your suggestion of splitting up the privileges and restrictions into separate lists, but I decided to present the restrictions in a different way. Let me know what you think.

[steveklabnik]

This looks good, but in the example code just below refers to the rules by number, and now that we've got two lists again, I'm sure they're wrong.

[nham]

@steveklabnik Actually I think they might be okay. I only see references to "privilege n" for some n, but none of the privilege numbers changed.