# SE-0293: Extend Property Wrappers to Function and Closure Parameters

**URL:** <https://forums.swift.org/t/se-0293-extend-property-wrappers-to-function-and-closure-parameters/42400>\
**Category:** Proposal Reviews\
**Created:** [December 1, 2020, 6:27pm UTC](https://forums.swift.org/t/se-0293-extend-property-wrappers-to-function-and-closure-parameters/42400 "2020-12-01T18:27:21Z")\
**Posts on this page:** 1\
**Showing post:** 45

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [December 4, 2020, 5:32pm UTC](https://forums.swift.org/t/se-0293-extend-property-wrappers-to-function-and-closure-parameters/42400/45 "2020-12-04T17:32:14Z")

</div>

A agree with the rest of the post, but there are a few important pieces:

> [@hborla](#):
>
> The only inconsistency is that the backing storage in a type context is private and with parameter, the backing wrapper type is exposed through the function type, but this inconsistency already exists today with generated memberwise initializers.

I'm sorry. I could not at all parse this sentence, even though it seems to be directly addressing my concern. Could you elaborate more on that?

> [@hborla](#):
>
> The design is intentionally "incongruent" with generated memberwise initializers for types with wrapped properties, because memberwise initializers today have a lot of complexity when property wrappers are involved. As stated in the proposal, this design aims to simplify the mental model of property wrapper initialization.

Sorry if I'm not clear, my "incongruence" means that you cannot exactly mimic the generated initializer with the provided feature. If we want to simplify the mental model, we need to make it possible to match the behaviour of the generated initializer with this feature.

> [@hborla](#):
>
> Initializing a property wrapper through a generated memberwise initializer is the only place where the programmer cannot choose how to initialize the backing wrapper (and only in some cases is this true), and sometimes the convenient `init(wrappedValue:)` synthesis is not available even if the wrapper supports it.

Let's be careful here. The choice of [pass by wrapper] and [pass by wrapped] is within the control of the author of the wrapper (but not of the lib author or the lib user). It is an important distinction since of the three parties, we want to give most of the controls of the call-site to the lib and the wrapper authors. This is one of Swift's guiding principles.

* * *

@hborla It does seem we're talking in a circle, and sometimes passing each other. If you'd kindly humour me for a moment, there are a few scenarios I would like your opinions on. Which among them are expected, and which are desirable? They of course can (and should) overlap. It'd also be great if you can elaborate on those that you deem desirable since I don't think they're ever desirable at any level of programming expertise and/or library authorship. So here goes;

1. We get different function types when implementing memberwise initializer with this feature:

2. If we use `@Lowercased` with `ForEach`, the array must contain `Lowercased` instead of `String`

3. `Binding` works with `ForEach` example, but won't work with normal function scenario (which are most of the `Lowercased` examples)

4. The lib user can use either pass-by-wrapper or pass-by-wrapped. The lib and the wrapper authors **do not** have any means to control that:

5. The unapplied method reference doesn't match the single-expression closure

If none of these are desirable, then _why_ are we paying for these? What is so desirable about the current behaviour that we can tolerate these (potentially common) surprises?

---

_[View the full topic](https://forums.swift.org/t/se-0293-extend-property-wrappers-to-function-and-closure-parameters/42400)._