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

[xwu (Xiaodi Wu)]

@Joe_Groff

Particularly, we want to propose: should marking a parameter as borrowing or consuming prevent it from being implicitly copied in the function body?

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).

@Joe_Groff

and likewise, a consuming T ought to act like a borrow binding

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

@Joe_Groff

One wrinkle in this plan is that the inout modifier already exists, and does not currently constrain the current value of the parameter from being implicitly copied, so we can't change its behavior without breaking source.

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.

@Joe_Groff

What do you all think?

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.

[Joe_Groff]

@xwu

@Joe_Groff

and likewise, a consuming T ought to act like a borrow binding

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

Thanks, fixed.

@xwu

@Joe_Groff

One wrinkle in this plan is that the inout modifier already exists, and does not currently constrain the current value of the parameter from being implicitly copied, so we can't change its behavior without breaking source.

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.

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

[Paul_Cantrell]

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!)

@Joe_Groff

let foo would still be implicitly copyable, whereas consume foo would not be.

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.

[xwu (Xiaodi Wu)]

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.

[Joe_Groff]

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.

[Jumhyn (Frederick Kellison-Linn)]

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.