I agree. It would also be coherent with the rules already in place for wrapped properties: if a protocol requires a property var foo: T
, then any wrapped property @Wrapper var foo: T
satisfies that requirement (it's the generated computed property var foo: T { get set }
that satisfies the requirement).
Not quite, but it still applies in this case.
It's not the interaction model being identical but the type signature being identical. A function func foo(x: Int = 0)
can be called as foo()
but wouldn't satisfy a protocol requirement since its type is (Int) -> Void
instead of () -> Void
. The same applies for @autoclosure
parameters: they can be instantiated as values, but they do not satisfy protocol requirements since func foo(x: Int)
has a different type signature than func foo(x: @autoclosure () -> Int)
.
In this case both func foo(x: Int)
and func foo(@Wrapper x: Int)
share the same type signature.
That being said, since the proposed rules are more restricting, it can be seen as a possible future direction. Until then (if the direction appears to be viable), users can use local wrapped variables as suggested.