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

[Jumhyn (Frederick Kellison-Linn)]

@xwu

I should add that, as I commented last time, I really thought the last revision was pretty much perfect .

+1.

I have similar initial reactions to @xwu to @propertyWrapper(api), and my immediate thoughts to the Core Team's feedback were almost identical:

@xwu

Personally, I think fulfilling requirements with the wrapped types makes the most sense to me.

I'm going to sit with this revision for a bit to see if it grows on me, but wanted to respond to this argument against the "witness-by-wrapped" strategy:

@hborla

I don't think this makes sense because the function will then be called differently in a generic context versus directly on a conforming type.

I, personally, am not super troubled by this, since if I were implementing the conformance myself, this would have to be the case anyway.

My example from previous pitch thread, which dealt directly with protocol witnesses

protocol P {
  func foo(a: String)
}

struct S {
  func foo(@Lowercased a: String) { ... }
}

func callFoo<T: P>(_ t: T) { t.foo("") }

let s = S()
callFoo(s)

Under the previous revision, a 'manual' conformance of S to P in order to let the above compile would require me to write something like:

extension S: P {
  @_implements(P.foo(a:))
  func _P_foo(a: String) { self.foo(a: Lowercased(wrappedValue: a)) }
}

I.e., writing out the conformance by hand already causes the call to occur differently in a generic context, and will similarly break wrappers like @Asserted as @filip-sakel called out.

I suppose there's an argument that the 'manual' conformance makes this obvious in a way that extension S: P {} wouldn't, but as @xwu notes this is getting into a niche corner case of an expert-level feature, so I'm not super troubled. Also, the potentially surprising behavior is relatively easily explained, IMO, to any user who is advanced enough to even be concerned about the difference between caller-side callee-side wrapper application.

I think it's reasonable to talk about applying wrappers at the "witness site" when they fulfill protocol requirements, i.e., at the point where the conformance is declared. We could still base init(wrappedValue:) overload resolution on the generic constraints of the extension that declares the conformance, and the 'magic' constants could just point to the extension to indicate "you were called through a protocol context, so your wrappers were applied at the witness site."