I read the (revised) proposal, and I have been following discussions about this feature for months. Overall, I get it, but I don’t really get it.
FWIW I definitely find this version more palatable than the “magic function” variant from the first version of the proposal. It certainly feels more aligned with the feel and direction of swift.
That said, to me, calling a function with the owned modifier on its argument would feel like a better way to specify that the lifetime of a variable should end at that point. Or a tightening of lexical scope as a way of dictating variable lifetimes.
If adding this move keyword is the preferred way of signifying that an otherwise copyable type should be moved instead of copied, i.e. that we always have to add this modifier to an owned function argument, unless the type itself is a speculative “move-only type”, then that’s the bit I kind of get. I see some analogue here with inout and the & modifier. If that’s the point, then I guess I can live with that.
Overall though, I don’t really see the value in this feature. I don’t buy the argument that adding move will signify to future maintainers of my code that the lifecycle should end and therefore they will not change the code without thinking twice. And I don’t really understand the argument for this feature rather than more formally defining lexical scope which seems like a much more intuitive way of defining a variable’s lifetime. The proposed feature seems to just be complicating that intuition further, and encouraging long and meandering functions that do many things.
I am an avid Swift user (starting pre-1.0) and I work on and with high-performance low-level and algorithmic Swift code on a weekly, if not daily, basis. Predictable performance, including regarding providing hints to the compiler for ARC optimisations is an extremely valuable prospect to me. And yet I can’t think of any cases where this proposal would benefit the work my colleagues or I am doing.
I don’t know if this is an issue with the description of the problem being solved here, whether it somehow just doesn’t affect me, or if I’m still just “not getting it”, but overall I’m still not in favour of adding this to the language. Maybe this proposal is just not the best place to start - maybe this only really makes sense in tandem with a few other features I’m not yet familiar with. But from my current perspective it’s a -1 from me.
edit: I kind of feel like this feature will be introduced anyway. In which case I am also more for the take spelling
——
Another edit: after sleeping on this I realised I’d feel far more comfortable with this as a language feature if it was only allowed when calling a function (doSomethingConsuming(myParam: take y)), as a parallel to useInout(myParam: &y).
There are numerous examples in the proposals along the lines of let x = move y that make little sense to me - what’s the advantage in ending one lifetime and simultaneously beginning an equivalent one? Is this really something we expect people to do?
In short: I would be +1 on a proposal that proposed only a way to spell out the fact that a function is consuming its argument: without the move re-binding, which seems uncompelling to me, and without the drop x semantics, which IMHO complicates intuition about the lifetime of variables within a given scope for unclear benefit.
But, since we don’t having “consuming” functions yet, this proposal still seems premature to me without others being made in tandem.