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

[Lantua]

@hborla

The argument we're trying to make is that these two kinds of wrappers already exist, and formalizing the distinction will help the compiler and other tooling help programmers better understand the property wrapper feature. It's not a completely new concept. The formalization is new.

We're trying to draw a line that wasn't there before, though. So it can be anywhere between a clean separation and a muddy gray area. At least, I don't think that the API vs Imp is a clear choice as is. That's why I'm trying to see what other (relevant) categorizations can be made.

@hborla

I think this is a mischaracterization of the change we made.

Since they're your changes, I'll take your word for it. Still, the old overload resolution has been advertised as fixing the memberwise-initializer and got past three pitches and two reviews relatively unscathed (well, depending on how you count this one). I'm confused whether this is a feature that got scraped or a design bug that got fixed.

In any case, I've been saying the same thing since pitch#2, so I can't say I dislike the change.

@hborla

This isn't true, though. For a wrapper to be implementation detail, it needs to support init(wrappedValue:) , which is not a requirement for property wrappers.

Impl isn't the baseline as you said , but that also applies that not all non-API wrappers are Impl given that they may not even implement any init(wrappedValue) and init(projectedValue). It may be more of a normal wrapper (@propertyWrapper), which supports wrapping local storage. Then Impl wrapper (@propertyWrapper(impl)) and API (@propertyWrapper(api)) sit on top of it.

It might also make sense for API to be the default, and Impl to be opt-in .