I do not doubt your understanding of the feature but the proposal claims that the transformation is achieved in two steps, or at least one gets the impression if you say that the implementation detail PW will compose a local property wrapper first before the final desugaring. In that sense it's not correct because the final transformation still should have the setter.
I get the point, but I personally do not buy the argument for synthesized code that is only sugar for the user (not speaking about the parameter handling from the compiler, which is one of the major motivations for this proposal in the first place). We're not really outruling the immutability of parameters, we would just copy them into a backing storage which happens to be function local instead being an immutable parameter.
Let me use the implementation PW example from the proposal again.
If this
func insert(@Logged text: String) { ... }
transforms to
func insert(text: String) {
@Logged var text = text
}
and finally to
func insert(text: String) {
var _text: Logged<String> = Logged(wrappedValue: text)
var text: String { _text.wrappedValue }
}
Then the result is artificially restricted and goes against the expected result for local property wrappers in Swift 5.4.
Not only that, if this restriction persists, why should I as a user use the property in such manner? Instead I would do the local property wrapper by hand and get the expected result.
func insert(text: String) {
@Logged var text = text
}
That said, implementation detail property wrappers on parameters start to lose the motivation for their existence. The only benefit is that I don't have to do the shadowing by hand, but then it ends up in removing the setter for me. That is simply not what I would expect from this feature.