For me it feels a smaller and simpler change (both to understand and to implement) compared to the pitch proposal.
Besides there are a couple of options available today, that allow ending variables lifetime early.
// 1. not so nice, but available now:
let other: T
do {
let x = ...
useX(x)
other = x
} // `x` lifetime ended
// `x` is moved to `other`
// 2. quite ugly, but available now:
let x = ...
useX(x)
let other = x // `x` is moved to `other`
guard let x = () as Void? else { fatalError() } // previous `x` lifetime ended
// 3. available today, not so bad:
var other = { () -> T in
let x = ...
useX(x)
return x
}() // `x` lifetime ended
// `x` is moved to `other`
// 4. might be available in the future (e.g. https://github.com/apple/swift/blob/main/userdocs/diagnostics/complex-closure-inference.md):
var other = {
let x = ...
useX(x)
return x
}() // `x` lifetime ended
// `x` is moved to `other`
// 5. future ideal, listing for completeness:
var other = do {
let x = ...
useX(x)
return x
} // `x` lifetime ended
// `x` is moved to `other`
By a way of analogy, it feels like having a programming language that only has a higher level "forEach" statement, and as we sometimes need a lower level alternative we are now having a discussion on introducing a "goto" statement without considering "while" and "switch" statements first, which might be just enough for a typical task at hand. (And remember, even if goto
can do much more compared to what "while"/"switch" can - goto is still considered evil and we don't have it in modern programming languages.)
I'd be very happy to be proven wrong and see some killer use cases that show superiority of "move" approach compared to nesting, just what I've seen so far (e.g. in the pitch description) doesn't look like a killer use case example.