Proposed modification to SE-0377: should explicit parameter ownership modifiers suppress implicit copying?

Hmm, in some ways I think this cuts against the grain of Swift's existing evolution history, where we removed var parameters as a shorthand for var bindings, and we moved the position of inout (where in its current place, as you point out, it would not be equivalent to an inout binding).

I assume this is a typo and that a consuming T would act like a consuming binding?

Another wrinkle, maybe: Inside a consuming func, would there be a consuming binding to self? I have entirely not thought through what that even means.

I think this is a little difficult to evaluate fully without having had a discussion on the topic of inout, borrowing, and consuming local bindings generally, which hasn't been pitched thus far.

Thanks, fixed.

That would be consistent, that a consuming func or borrowing func imposes the no-implicit-copy constraint on self in the method's body.


Thanks, Joe, this is extremely helpful. (Sorry for asking all these dense-headed questions; hopefully my incomprehension can be a useful guide in developing the user-facing surface of these features!)

I think I’m finally catching up. Maybe. IIUC, under the proposal at the top of this thread, these two would be fully equivalent:

@noImplicityCopy let foo = consume bar  // syntax here is hypothetical; not sure
                                        // if you’re also proposing to support
                                        // the @noImplicityCopy attr on local vars

consume foo = bar

If the above is correct, the proposal at hand here does make good sense. I’d kind of wish for it to be spelled with a gerund and an explicit let:

consuming let foo = bar

…which makes far more immediate sense to my brain, though I understand that the need for conciseness might outweigh that clearer spelling.


Yeah, I think this goes to the point that we're trying to align SE-0377 to a future feature which hasn't yet been laid out for the community, where essentially we're now trying to piece together that proposal's detailed design section in Q&A format.


That's fair. At a high level, I think it'd be OK to say we want to hold off on accepting SE-0377 for the time being until we've had time to also pitch and review these other features.


I mostly agree with the intuition laid out in the OP. It makes sense to me to have the explicit use of these ownership modifiers imbue the code with a more extensive "I care about the lifetime stuff for these parameters" meaning.

Procedurally, I'd definitely want to see this direction fleshed out more, but I'm not sure it would need us to hold off on acceptance of SE-0377 as is... as long as there's not an interleaved release between the two, and we'd be fine with SE-0377 if the pitched behavior gets shot down in review, I don't see why we couldn't run this as a completely separate follow-up proposal.