I am +1 for this proposal.
I think the rationale for having the wrapping done by the caller is well laid out and is the correct choice. The proposal also does not preclude a callee from accepting a passed-in value and wrapping it within the called method, so this proposal also allows for both approaches.
The concrete example in my own coding experience related to this proposal is the case of propagating bindings through a
ForEach in SwiftUI. I believe the proposal addresses that case very well and will lead to more expressive code.
Considering that case as well as the other examples in the proposal, I think the problem addressed is signifiant enough to warrant the addition. I also believe the proposal does fit well with the feel and direction of Swift.
This is an intricate feature, but I think the proposal adds it to the language in a straightforward and consistent manner.
I think it will take a considerable amount of knowledge to use this feature well in libraries and frameworks, understanding property wrappers themselves and then the implications of using a property wrapper for a parameter. I think the cognitive load will be much less for clients of those APIs, where specific property wrappers are used and idiomatic use will likely be clear from example code or documentation, even without a deep knowledge of property wrappers or this feature.
I read the proposal and feedback for this review closely, but did not follow the previous review closely.
This proposal also seems to be a great example of the Swift Evolution process at work. I really appreciate the work done by the proposal authors and everyone who contributed to the reviews.