RFC: moving out of enums

[nikomatsakis]

The existence of option::unwrap() (and soon reuslt::unwrap()) points at a more general problem. There is no way to move something out of an enum. I think we should be able to solve this more generally. My proposal is something like this:

alt move expr {
    foo(a, b, c) { ... }
}

In here, a, b, and c are not pointers into expr but rather the values themselves. They are moved out of expr, which must be something movable.

You could then write option::unwrap() like so:

fn unwrap<T>(opt: option<T>) {
    alt move opt { some(v) { v } none { /* ok */ } }
}

This fits best with adding move back as a unary operator (of which I am in favor). Basically, alt over an expression that is an explicit move causes the bound variables not to be region pointers into the struct but rather the values themselves (i.e., the types will differ). Depending how explicit we want to be, last use analysis is still needed in that last example to convert the use of v from a copy to a move.

[catamorphism]

This seems useful. I support it.

[graydon]

I guess. Kinda lukewarm about it. Requires the enum itself gets de-initialized, so only possible on a local. What's the motivating case?

[nikomatsakis]

It's possible on anything that's movable, which includes both rvalues and local variables (it could be wider still than our current rules, as well).

Motivating cases from pfox recently was something like this:

let res: result<filedesc,fail> = some_io_operation();
if res.is_failure() { ... handle failure; ... }
let filedesc = res.get();

Right now this requires that the filedescriptor by copyable (and hence not a resource). I added an (unsafe) unwrap() method that handles this, but I was thinking that it would be nice to be able to handle this in a general way, rather than adding it to each type that requires it.

This came up for @brson with options (that was what motivated the original option::unwrap()) in which he had some shared option<T> and he was swapping it out with none and then wanted to use the contents. I forget the full situation.

I can imagine something similar being useful with, say, a unique record that you would like to pull apart:

fn foo(-point: ~{x: int, y: int}) {
    let {x, y} = move point;
}

This may work today with last-use analysis, I don't know.

[nikomatsakis]

To clarify my cryptic comment about the set of movable things being potentially wider, we could also allow anything "uniquely referenced" from the stack, so some chain l.f.g.h where l is a local and only unique pointers are dereferenced (note: interior fields are not dereferences). Moving such a path would "de-initialize" each subpath (l, l.f, l.f.g, and l.f.g.h). I think that's the most general set of things we could easily support.

[nikomatsakis]

Well, I guess it's enough to deinitialize l. Anyway.

[graydon]

We don't track init-ness of paths-within-locals, only locals themselves. Typestate is pretty shallow.

[nikomatsakis]

I know we don't do it now. We could of course track the interior of variables (in some cases) but that's not quite what I meant. I just meant that we could allow moving out of an inner content and just deinitialize the variable as a whole when you're done. I guess you could achieve what I'm talking about with a move into an infallible pattern, e.g.,

let {f: {g: x, _}, _} <- l

in place of

let x <- l.f.g

but of course that doesn't work with fallible patterns (hence the bug)

[nikomatsakis]

Thinking more on this, I've decided to close this issue and instead open some narrower requests. =)

[pcwalton]

Reopening this. The lack of this is causing lots of copies (including file-sized ones!) Consider what one has to do with the return value of io::read_whole_file_str...

[pcwalton]

I think this may "just work" if we implement the suggestion in issue #2517, which is to require & pattern bindings for by-reference and make pattern bindings by-copy/by-move by default. Then it basically falls out of move being a unary operator: a "by-value" binding site automatically becomes a move if the expression in the alt head used the unary move operator.

In other words, I think there's nothing special we need to do to make this work: we just need the unary move operator proposal and the explicitly-by-reference pattern binding syntax.

[nikomatsakis]

I agree, if we go with #2517, this should just work (and then it would be compatible with last-use).

[pcwalton]

This is now implemented.

[eholk]

Did anything change within the last couple of ours around this code? I tried to move out of an enum earlier today and got runtime errors, probably related to double-destructing something. I had to go back to my move macro.

[eholk]

I just checked on test/bench/pingpong.rs, and move cannot replace move_it! there yet. I think it's a bit premature to call this bug fixed.

[bblum]

I am implementing this by adding an transitionary move keyword, similar to copy.

The current rule is that moving in a pattern is legal if (a) there is no pattern guard, (b) the matched thing is an rvalue, not an lvalue, (c) not "move x @ ...", and (d) no refs and moves in the same pattern.

When match statements turn into by-copy-by-default, both the 'copy' and 'move' keyword should be removed and the semantics inferred instead. Rule for inferring copy vs move:

• if matching lvalue (and not a last-use of the lvalue?) then copy
• else if any 'ref's exist in the pattern or there's a pattern guard then copy
• else if x@... then copy x
• else move

[bblum]

This is done. Syntax/inference may get upgraded. See #3271.

[eholk]

Does this work well enough to get rid of the move_it! macro in pipes and other places?

[nikomatsakis]

@eholk yes.

[bblum]

see 8d00603; the one case I didn't get was moving out of a struct field in its destructor. it looked like that could be replaced with SharedMutableState but i didn't think too hard about it.