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

[hborla (Holly Borla)]

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.

[filip-sakel]

Sorry for taking so long to reply.

@Jumhyn

This ends up being a pretty fine distinction, so it might be too subtle to surface at the per-wrapper-instance level. I also don't love that the "default" version likely ends up being the API-level one, rather than the implementation-detail one.

ETA: and, if the particular feature set of a given wrapper doesn't support usage in a particular position (e.g., no init(wrappedValue:) ) then an appropriate diagnostic would be emitted at the wrapper use-site.

This is, in my opinion, better solved by init-based "API-ness":

@filip-sakel

Wrappers can have different generic constraints on overloads of init(wrappedValue:) , in which case the API significance ("API-ness") of the wrapper will (likely) be conditional. This means that Wrapper<Int> may be API-level, whereas Wrapper<Void> implementation-detail. We expect that to be pretty rare, but I'm thinking that perhaps future ways of explicitly stating API significance could revolve around the special init(wrappedValue:) and init(projectedValue:) . This approach raises a lot of other questions and could very well unimplementable.

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.

[Jumhyn (Frederick Kellison-Linn)]

Yep that makes total sense as a design direction. No arguments from me!