[Pitch #3] Property wrappers (formerly known as Property Delegates)

Evolution Pitches
142

Is it explicit? @Published carries no type information, it's just a spelling. This could have been spelled @Publisher, @Dog, or @Blah, and I have to refer to the definition of it to see what $ means.

143

It's the name of the type itself, it's not "just a spelling". You can then refer to the type's documentation, knowing that it defines a behaviour.

1 Like
144

To me, this is the magic. I have to refer to the documentation to see what @Published is or use type inference to know what $password becomes. Without a property wrapper, I would have an explicit type of Publisher<String> that doesn't require the documentation or inference to figure out.

For the spelling point, the compiler guarantees that the type Publisher is a Publisher. Here, we instead spelled it Published and it vends a Publisher.

Naming is completly arbitrary in property wrappers.

145

I don't get this. Whether the variable is spelled:
var publishedPassword: Published<String>
or
@Published var password: String,
there are two types you need to know in order to understand the behaviour: Published and String. One just involves fewer characters to type than the other, while being equally explicit.

7 Likes
146

No, there are 3 types. @Published, Publisher<T>, and String, and you actually don't know about the type Publisher<T> from the interface of the property, it's hidden.

Here's an alternative and more explicit interface for property wrappers, as an example:

@Wrapper(Publisher<String>) var password: String

You get all the type information you need from the definition of it. Obviously there are cases of wrappers that do logic besides creating a new type, but this is just a simple examples to illustrate how the current solution is not adequately explicit.

147

@Published var s: String means that you have a Published<String>. Where's the third type?

Or maybe we're arguing about preferences.

1 Like
148

Again, there is nothing EXPLICIT about the interface @Published var s: String that tells me the type of the wrapped value.

Here is an alternative which tells you the type EXPLICITLY: @Wrap(Publisher)

Do you see the difference? Swift favors explicit design. The current property wrappers design hides the type behind user spelled wrappers that you have to click into and memorize.

149

There's no Publisher type, only Published type if you declare s like that.

3 Likes
150

Do you always type your optionals as Optional<Wrapped> rather than Wrapped?. I use the latter, and according to your arguments you must use the former. Potayto, potahto. The pitch proposes a feature to explicate the link between wrappers and their wrapped types in a new way. It's unfair to claim it's not explicit, though: it's a new way to be explicit. You're free to not like it, though.

7 Likes
151

Iā€™m somewhat sympathetic to the objection @ebg is expressing here: the type of $property is completely opaque from the declaration of @Wrapper var property: Type. Thatā€™s the third type that they are concerned about. The comparison to Optional<Wrapped> and Wrapped? is erroneousā€”theres no equivalent to the $ syntax which vends an unknown type that we havenā€™t declared in our code. Itā€™s felt weird and magic to me as well having $stateVar vend a Binding.

2 Likes
152

I've been mulling over the concept of wrapperValue and am still not sold on its utility. It's unfortunate that the meaning of $property cannot be inferred without reading the implementation of the property wrapper.

The proposal's Ref/Box example is not compelling. I'm not sold on the existence of Box; Ref could declare an init(initialValue:) using a captured local reference for storage:

init(initialValue: Value) {
    var value = initialValue
    self.init(read: { value }, write: { value = $0 })
}
1 Like
153

Iā€™m being serious and kindly asking, have you read the proposal or just trying to push your opinion on how bad the feature is designed through into our minds loudly?

As pointed out above there are 2 types:

  • Published<T> - a type that is marked with @propertyWrapper attribute which allows it to behave itself like an attribute, hence the @Published custom attribute syntax (Iā€™m not sure why you sometimes calling it Publisher instead, typos?)
  • String

For convenience on custom attributes, which start with a capital letter unlike compiler attributes which usually start with a small letter, you can omit the generic types (if present) in most cases.

@Published<String> var value: String
@Published var value: String

Both these forms are the same. If you still donā€™t understand something I highly encourage you to take a few minutes and read the full proposal. :slight_smile:

154

The precedence spelled out in the language currently is $0, $1, etc. in closures for referencing passed in variables. We're started to see $ codified to mean "generated by the compiler"

155

To my surprise, it seems Delegating access feature is still intact in the proposal.

1 Like
156

What exactly do you mean by that?

157

If wrapperValue (not value) is present in Property Wrapper, it'll override $variable, creating the 3rd type @ebg is concerned about.

158

Yeah the justification for that feature is controversial that is a fact.

159

I wonder if what makes wrapperValue seem necessary is the fact that Swift doesnā€™t have move-only (and non-copyable) types?

160

What was the justification?

161

Respectfully, I think you're missing the difference between Published and Publisher, which might be causing a lot of confusing.

Publisher (with a R) is the actual type that the wrapper value is. Publisher | Apple Developer Documentation

Published (with a D), is a user-defined name for this behavior. To clear things up, maybe let's rename this behavior @CatDog. We can do that because this feature uses arbitrary names without anything explicit required for the wrapper value.

If I see

@CatDog var str: String
$str

in the code, I don't know what the wrapper value is.