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

[Lantua]

I don't see anything that could block that idea in this pitch. If anything, this'd make it more likely to be added later.

[xAlien95 (Stefano De Carolis)]

@From the edited Extending property wrappers to patterns section

Enabling the application of property wrappers in value-binding patterns would facilitate using the intuitive property-wrapper syntax in native language constructs, as shown below:

enum Review {
  case revised(Traceable<String>)
  case original(String)
}

switch Review(fromUser: "swiftUser5") {
case .revised(@Traceable let reviewText),
     .original(let reviewText):
  // do something with reviewText
}

@hborla, is this intended? I thought the goal was to hide the backing storage's type unless the property wrapper creator doesn't explicitly make it public/accessible through the projected value. If we have

if case .revised(@Traceable let reviewText) = .revised(traceable) { ... }

then we also have

if case @Traceable let reviewText = traceable { ... }

i.e. assignment by backing storage. @filip-sakel's take, while more complex, was in my opinion more in line with the contents of this proposal.

enum Review {
  case revised(History<String>)
  case original(String)
}

switch Review(fromUser: "swiftUser5") {
case .revised(@Traceable var $reviewText):
  // uses init(projectedValue:)
  // reviewText: String, $reviewText: History<String> available
case .original(@Traceable var reviewText):
  // uses init(wrappedValue:)
  // reviewText: String, $reviewText: History<String> available
}

[hborla (Holly Borla)]

@xAlien95

@hborla, is this intended? I thought the goal was to hide the backing storage's type unless the property wrapper creator doesn't explicitly make it public/accessible through the projected value.

If the associated value type is the backing wrapper type, it's already exposed. I only changed it from Filip's take because this is what was suggested in the decision notes from the first review:

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

The suggestion was for pattern matching to "unwrap", not create a new property wrapper.

Honestly, I was hesitant to include an example at all, because this direction obviously involves design work and the example raises a lot of questions. Remember that this is just a future direction and the feature is orthogonal to this proposal.