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

[xAlien95 (Stefano De Carolis)]

Thank you for re-pitching this proposal. It looks like all the suggestions emerged in both the previous pitch and its review have been considered and implemented, along with clarifying the behavior of wrapped @resutBuilder parameters.

In the review of SE-0293, the core team suggested the following approach:

@Chris_Lattner3

5. The functionality that allows "unwrapping" property wrappers in the pattern of a closure argument (e.g. { (@Binding item) in ) could alternatively be imagined as an orthogonal feature that applies to all patterns. If it were, such an unwrapping could work consistently in other places where patterns exist, for example for @Binding item in items , in switch case patterns, if case , etc. It would be interesting to explore such a direction.

Being able to use property wrappers in patterns seems interesting and more general. Has this alternative direction been explored by the authors?

---

The proposal adds init(projectedValue:) in order to solve the issue of passing the storage a projected value. This however forces API developers to not use the projected value as a projection but in some way as a public mean to access/instantiate the private storage instance, thus limiting the design space. The proposal states that "one of the motivating use-cases for property-wrapper parameters is the ability to pass a projected value", but in reality it should be "the ability to pass a storage instance".
In the previous pitch thread, the authors observed that having $ attached to a parameter label to specify that it's the storage that needs to be passed is counterintuitive given that $ indicates the projected value. I agree, but I wonder if the ability to assign a storage instance to an already initialized wrapped property should be transparently available to users as a general feature.

---

From the proposal:

For closure parameters, the property-wrapper attribute is not necessary if the backing property wrapper and the projected value have the same type, such as the Binding property wrapper from SwiftUI:

let useBinding: (Binding<Int>) -> Void = { $value in
  ...
}

Consider the following example:

let useBinding: (Binding<Binding<Int>>) -> Void = { $value in
  type(of: value)  // returns 'Binding<Int>' or 'Int'?
}

We can have both @Binding var value: Binding<Int> and @Binding @Binding var value: Int and without explicitly knowing which are the property wrappers attached to value, we cannot know its wrapped type.