SE-0293 (second review): Extend Property Wrappers to Function and Closure Parameters

[wowbagger (冀卓疌)]

This proposal is very well-written, and the future directions are very well-thought out. It's also a significant improvement from the previous revision.

Before I give my review, I would like to ask for some clarifications:

By default, unapplied references to functions that accept property-wrapped parameters use the wrapped-value type in the parameter list, and the compiler will generate a thunk to initialize the backing wrapper and call the function.

[...]

func log<Value>(@Traceable value: Value) { ... }

[...]

The compiler will generate a thunk when referencing log to take in the wrapped-value type and initialize the backing property wrapper. [...]

{ log(value: Traceable(wrappedValue: $0) }

If the user has already defined a function that takes the entire wrapper storage

func log<Value>(Traceable<Value>) { ... }

(e.g. an existing API like those in SwiftUI that take Binding arguments), would the compiler consider it as an erroneous redeclaration, or does the compiler have a way to work around it to help with migration from older APIs to newer ones that use property wrapper-annotated parameters?

---

In addition, I would like to add another reason for not supporting passing a property-wrapper storage instance directly: It's ambiguous when the wrapper and wrapped types are the same.

@propertyWrapper
struct Foo { /* ... */ }
func bar(@Foo foo: Foo) { /* ... */ }
let foo = Foo( /* ... */ )
bar(foo) // treat foo as a wrapped value or wrapper storage?

---

A very much delayed response to 2 posts in the latest pitch thread

@filip-sakel

@wowbagger

The call site semantics still feels dangerous to me, because the parameter's type ( Wrapped or Projected ) doesn't match the function's type at the parameter's location ( Wrapper ).

If I understand correctly, you think it's dangerous that the types used in the transformed function and the call-site are different –– the former uses the backing storage's type, when the latter uses the wrapped or projected values' types.

I don't see how that is dangerous, though. Could you elaborate on that?

@wowbagger

I wonder if it can be helped by requiring the call site parameters to be annotated with @Wrapper for both wrapped and projected values. E.g.

func foo(@Wrapper value: Wrapped) { /*...*/ }
foo(@Wrapped value: wrapped)
foo(@Wrapped $value: projected)

I don't see how that would help.

@xAlien95

@wowbagger

The call site semantics still feels dangerous to me, because the parameter's type ( Wrapped or Projected ) doesn't match the function's type at the parameter's location ( Wrapper ).

From the user perspective, the Wrapper type will never be considered. Also, the backing function will be unreachable, so if a function with the same type signature of the backing one exists, it wouldn't conflict.

I didn't read the proposal in full at the time, and misunderstood the type signature of functions that use property wrapper-annotated parameters. Now that I've finally read the proposal fully, I see that there is nothing dangerous with the function signature. Sorry for this much delayed response.