Still curious whether it’s desirable for the
wrappedValueoverloads to influence the type of the passed argument in potentially non-obvious ways.
Overload resolution can't influence the type of the wrappedValue argument in an unexpected way, because it's an error to have a wrappedValue parameter type that isn't compatible with the type of var wrappedValue in the property wrapper. autoclosures of compatible types are allowed, though.
I don't think the need for this overload resolution behavior will be super common, but I do think it's reasonable to want. Personally, I think the most compelling argument for applying the property wrapper to the argument at the call-site is the ability to initialize the wrapper differently, e.g. through a projected value or by passing the backing wrapper directly.
If the proposed semantics of this transformation as written are desired, would it be more apt to refer to this feature extension as "function argument wrappers" rather than "function parameter wrappers"?
FWIW, here's the terminology I've been using: You attach a property wrapper custom attribute to a parameter declaration, and the property wrapper is applied to the argument at the call-site.