Great!
Even without considering property wrappers with additional initializer arguments, this does expose one potential gotcha that I can think of. For property wrappers with reference semantics, a function author may incorrectly assume that with a setup like:
@propertyWrapper
class Box<T> { ... }
func foo(@Box arg1: Int, @Box arg2: Int) { ... }
the transformation rules ensure that foo will be called with fresh Box instances for each argument. However, if a too-clever client does something like:
let box = Box(wrappedValue: 0)
let bar = foo
bar(box, box)
Then suddenly the author of foo may have to worry about exclusivity violations that they thought weren't possible.
Do you have thoughts on the tradeoffs of implementing a transformation for function references like I wrote above, where the problematic line in this example would become:
let bar = { (arg1: Int, arg2: Int) in foo(arg1: Box(wrappedValue: arg1), arg2: Box(wrappedValue: arg2)) }
?