Thanks, I’m already aware of the thread you’re talking about and the idea to give property wrappers static storage. The parser could handle additional arguments to the @propertyWrapper attribute. In any case, we’re moving the api explicit spelling to future directions.
1 Like
Sorry for taking so long to reply.
This is, in my opinion, better solved by init-based "API-ness":
Otherwise, I think users will end up being more confused with wrappers applying to different places. Furthermore, as discussed in updated proposal text, wrappers should be pretty similar to users. A wrapper author, however, should be aware of the differences when their wrappers are used in public API or when the wrapper deals with side effects.
1 Like
Yep that makes total sense as a design direction. No arguments from me!
1 Like
Hi, I've had my eye on this proposal but not been following too closely. Could the proposal allow a solution like the following for dependency injection, or would it be descoped to a future direction?
init(
@DI var myHelperService: HelperService,
@DI var myOtherService: OtherService
) {
// …
}
My expectation here is that the argument would detect the property wrapper's init() and infer that as a default argument, but you could still manually specify a value via init(wrappedValue:).
No, this feature does not infer default arguments. Note also that the discussion has moved over to a 5th pitch thread.
1 Like
Would you be ok with me kicking off a re-review of this tomorrow (monday)?
3 Likes
Yes, thank you!
Thank you for all the great work on this, the 3rd review is now live. I'm not sure what the emoji is for a function parameter, but here's a wrapper! 
-Chris
5 Likes