[Pitch] Move Function + "Use After Move" Diagnostic

[Jumhyn (Frederick Kellison-Linn)]

@Michael_Gottesman

I wouldn't think of move being as being passed a binding. Instead the way to think about it is that you are moving the current value of the binding out of the binding and returning that value as a return value. move is not returning a copy of the value in the binding... it is returning the actual value that was in the binding.

Okay, I can get behind that way of thinking about it—but either way, move is still a function which somehow acts on (or is "applied to") bindings:

@Michael_Gottesman

This follows from move being applied to the binding ( x ), not the value in the
binding (the value returned from getValue() ).

which isn't something that exists for Swift functions generally, so it just feels a bit weird to model this as a function when its semantics deviate pretty dramatically from functions in Swift today. I think @fclout has good questions in this regard:

@fclout

One thing that's not addressed here: what happens if I try to move from something that isn't a local binding? Can I move the result of a function call? Can I move out of things that have setters, like properties and subscripts? Can I move a value out of an async let binding, of a binding with property wrappers, of a global variable?

AFAICT we don't really have the terminology to talk about how move behaves as a function in the language today except to say "oh you shouldn't really think of it like a normal Swift function, it's just compiler magic."

That said...

@Michael_Gottesman

Remember that move is applying __owned for its argument (which I am going to be formalizing soon hopefully into the language)

I'm glad to hear we are pulling some of these underscored qualifiers into the language proper. If the end goal is to have Swift end up in a place where the ownership features are fleshed out enough that any user could define their own equivalent move function, I don't have any qualms about the fact that in the interim it would have to be supported by some compiler magic.

@Michael_Gottesman

We are on purpose not using discardable result since we want the user to explicitly have to show that they do not want to use the result. This is an expert feature where we want users to be explicit. So discardable result is inappropriate.

Like I said, that sounds like a great justification for the drop function. It doesn't make sense to me to simultaneously argue that it's an expected/supported use case for the result of move to be discarded, but it's not appropriate to mark it @discardableResult. I'm also not that compelled by the argument that it's an expert feature—if that's the case, shouldn't we trust experts to use or discard the result as appropriate?

I guess I'm just not seeing the danger of an erroneously discarded move result. If a user meant to write

let y = move(x)

but instead wrote just

move(x)

what's the danger? It seems to me like the diagnostics would make it apparent quite quickly what the issue is.