This is very nicely subsetted out from the full feature set. Obviously I look forward to generics-compatible non-copyable types, but I agree that this has use cases on its own, and it is definitely easier to review these proposals in chunks rather than all at once, even as we treat them as part of a whole. Kudos!
People already seem to be discussing a number of things I'm interested in, especially "should the attribute affect the type's generic parameters" because that does affect future proposals. There's only one thing that's jumped out at me that no one's mentioned:
For a local
consumefunction parameter, that is not itself consumed,
deinitruns after the last non-consuming use.
What does "after" mean here? The example shows a non-consuming use in a function call, followed by deinitialization on the next line. What if there are nested function calls? Thus far, Swift does not share C++'s concept of a "full-expression", so would it happen between the inner and outer calls, like
inout ending/cleanup? If the function is inlined, could the
deinit happen before it's even complete? And if I want my binding to live longer, I can certainly use an explicit
consume x, but the cost of forgetting that could result in a bug.
Between the discussion about class instances being released unexpectedly early (which I'm having trouble finding at the moment), and the precedent set by Rust, I would appreciate more discussion on why the default behavior isn't to deinit at end of scope, with an early
consume allowing for more control when needed.
EDIT: I can think of one reason why this rule isn’t sufficient: directly passing an owned return value to a
borrow parameter, or discarding one. It would make sense to me if those behave like
inout while named bindings behave like
defer, just as struct members and enum payloads have their own ordering.