Jumping on this discussion, as I feel there is something important missing regarding the property wrapper, especially regarding the projectedValue that has been already discussed during the original property wrapper proposal and here.
By sharing a very relatively classic use case of app development that I encounter, I would like to show how convenient it will be to be able to declare a projectedValue requirement on a protocol variable at least - if it is not possible to specify this requirement on the whole property wrapper to use on the protocol.
Today, I face a blocker regarding the adoption of property wrappers:
Good practice in a relatively big project is to have protocols for injecting and connecting the different app layers such as services with views or view models. In particular, they allow mocking these types for unit tests or for SwiftUI previews. This is a must-have on a large application. Combine introduced @Publlished, a very convenient property wrapper that exposes a publisher by the projected value as well as exposing the value itself in R/W. This publisher makes our API very clean and straightforward (only one variable). But the moment we introduce protocol, we no longer can benefit from the projected value syntax ($).
So we need ether
- to declare two variables for the same data (the r/w value and the publisher),
- to do a hack that consists of creating a class that contains the
@Publlishedvariables, and make the protocol inherit from this class. Allowing the share @Published vars with all the implementations of the protocol by inheritance.
I think it will be nice to have a sugar syntax that defines directly on the variable the projection requirement. Even if allowing to use $ in a second variable declaration will solve the use case.
To conclude, If you have any alternative to share for my use case, I would love to read about them too 