[Pitch #3] SE-0293: Extend Property Wrappers to Function and Closure Parameters

[Lantua]

To be clear, I'm in favor of adding init(projectedValue:) for function argument wrapper, but I'm not sure if we want to add init(projectedValue:) to original property wrapper.

For function argument, it'd be extremely useful for those I called shared storage wrapper that I found in my last survey:

@Lantua

Shared-storage wrappers use some mechanisms to share the wrapped values between instances, e.g., Binding , UnsafePointer .

[...]

• Shared storage : Binding , UnsafePointer , Namespace *, Atomic , NSCopying , ThreadSafe 1 2

but it doesn't do much for the original PW. size-wise, they don't differ too much from custom init:

$value = projectedValue
_value = .init(projectedValue: projectedValue)

though it may allow for inlined init(projectedValue:)

@Wrapper var $value = projectedValue

---

@DevAndArtist

The original PW functionality does not and probably cannot support this feature.

I think it's fine to have the initializer be optional, just like init(wrappedValue:). If you define it, the type must match the projectedValue, and you can then use var $value = ....

@DevAndArtist

• split the PW which you‘d otherwise extend with init(projectedValue:) into two separate PWs
• provide multiple necessary overloads on functions where the proposal uses $ for parameter labels

The first one probably wouldn't work since we'd just be shifting the need for init(projectedValue:) into one of the two PWs.

The second one would work for original PW, but I don't see how that could improve function argument wrapper.