Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize moves to allow moves out of any owned content #4384

Closed
nikomatsakis opened this issue Jan 8, 2013 · 9 comments
Closed

Generalize moves to allow moves out of any owned content #4384

nikomatsakis opened this issue Jan 8, 2013 · 9 comments
Assignees
Labels
A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system
Milestone

Comments

@nikomatsakis
Copy link
Contributor

This program should be legal

struct Foo {
    v: ~[uint]
}

fn make_foo() -> Foo {
    Foo { v: ~[1, 2, 3] }
}

fn main() {
    let v = make_foo().v;
    for v.each |i| { io::println(fmt!("%u", *i)); }
}

But it yields:

/Users/nmatsakis/tmp/bar.rs:10:12: 10:24 error: moving out of immutable field
/Users/nmatsakis/tmp/bar.rs:10     let v = make_foo().v;
                                           ^~~~~~~~~~~~
@nikomatsakis
Copy link
Contributor Author

Presumably the problem here is how borrow checker treats moves out of fields contained in rvalues. But that code needs to be somewhat re-worked in general.

@nikomatsakis
Copy link
Contributor Author

Oh, actually, this is not specific to rvalues really. It's just a generally unnecessary limitation of borrowck.

@bblum
Copy link
Contributor

bblum commented Jan 11, 2013

I'm confused why this isn't specific to rvalues. Isn't let f = make_foo(); let v = foo.v; illegal?

This seems to me like a legal special case because it could be syntax sugar for let Foo { v: v } = make_foo().

@nikomatsakis
Copy link
Contributor Author

I am editing the title of this issue and expanding it. We should allow moves out of arbitrary owned content. Most of the system is setup for this already, I think the only problem is that borrow check flags such moves as illegal. (But there might be trans work needed to) Examples of things that ought to work but do not:

let a = b.c; // where b.c is an owned path and c has linear type
let d = e[f]; // where e is ~[T] and T is linear

In some cases these can be expressed today using match statements. I see no reason for match statements to be more expressive than other kinds of expressions; moreover, they do not allow e[f].

Currently, the moves code and liveness analysis will allow such moves. They would cause the local variables b and e above to be considered "partially moved" and thus unusable. But then the borrow checker would flag an error for moving out of something that's not a local variable.

@nikomatsakis
Copy link
Contributor Author

@bblum your example is illegal today but I don't see any good reason for that restriction.

@graydon
Copy link
Contributor

graydon commented Apr 30, 2013

assigning bug; change assignment if you disagree

@ghost ghost assigned nikomatsakis Apr 30, 2013
@nikomatsakis
Copy link
Contributor Author

Some FIXMEs related to bits of code that will have to be adjusted.

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue May 29, 2013
…terns into

borrow checker and generalize what moves are allowed. Fixes a nasty
bug or two in the pattern move checking code. Unifies dataflow code
used for initialization and other things. First step towards
once fns. Everybody wins.

Fixes rust-lang#4384. Fixes rust-lang#4715. cc once fns (rust-lang#2202), optimizing local moves (rust-lang#5016).
bors added a commit that referenced this issue May 29, 2013
Move the computation of what data is moved out of `liveness` and into `borrowck`. The resulting code is cleaner, since before we had a split distribution of responsibilities, and also this avoids having multiple implementations of the dataflow code. Liveness is still used to report warnings about useless writes. This will go away when we get the control-flow graph code landed (working on that).

Also adds borrow checker documentation.

Fixes #4384.
Required to support once fns and to properly fix closures (#2202).
First step to generalize our treatment of moves somewhat as well.
@Blei
Copy link
Contributor

Blei commented Jun 6, 2013

The example program compiles and runs now. Can this be closed?

@nikomatsakis
Copy link
Contributor Author

Yes, fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

4 participants