[Pitch #3] SE-0293: Extend Property Wrappers to Function and Closure Parameters

[xAlien95 (Stefano De Carolis)]

@Lantua

One thing I haven't seen discussed: does function with wrapped argument satisfy protocol requirement?

I would say "yes" if we don't drop the following requirement:

@Lantua

Property wrappers on function parameters must support init(wrappedValue:) .

Rationale : This is an artificial limitation to prevent programmers from writing functions with an argument label that cannot be used to call or reference the function.

Maybe we can drop this requirement. We don't seem to have any problem with unusable function:

func foo(_: Never) { } // ok...

With a required init(wrappedValue:) (or init(wrappedValue:params:)) the function type signature is preserved, so it makes sense to satisfy a protocol requirement. Users would also be free to add or remove property wrappers to their function parameters with no effects other than the ability to use the projected value in the function body.

Without that requirement, we should probably need a specific error: the general

Type 'S' does not conform to protocol 'P'
Do you want to add protocol stubs?

would add a separate function with apparently the same type signature of the original, but with all the property wrappers removed. That may be confusing.

---

@hborla

Good question. I've been thinking about witnesses and overrides and I think the answer is that a function with property-wrapper attributes can only be a witness or override if the original has the same wrapper attributes.

Currently, property wrappers cannot be declared in protocols. Are you referring to subclassing only?

FWIW, result builder variables/parameters are allowed to be overridden by non-result builder properties/parameters, but I don't know if it was explicitly intended to work this way.

---

@wowbagger

The call site semantics still feels dangerous to me, because the parameter's type ( Wrapped or Projected ) doesn't match the function's type at the parameter's location ( Wrapper ).

From the user perspective, the Wrapper type will never be considered. Also, the backing function will be unreachable, so if a function with the same type signature of the backing one exists, it wouldn't conflict.