SE-0258: Property Delegates

[Douglas_Gregor]

@anandabits

Since it is possible to write storage wrappers manually I am surprised that the proposal makes no accommodation for a frequently voiced concern that backing storage is typically an implementation detail that is private . A syntactic sugar proposal like this one should acknowledge and support widespread use cases where the pattern is written explicitly.

Just to be clear, does something like the private(storage) future direction meet your criteria here, or do you feel that there is a deeper problem with the design that needs to be addressed?

@anandabits

Why doesn't CopyOnWrite just rename delegateValue to value and use private backing storage? Why should its users need to say $foo` in order to write? What is the perceived advantage of this design?

I think we can provide a more natural CopyOnWrite wrapper using generalized accessors, since modify is able to do the uniqueness check and efficiently yield the unique value. I've been meaning to try it with the toolchain, because _modify is in the compiler already. Should the property delegates proposal examples depend on this experimental feature? I guess it could.

@anandabits

Why doesn't Box just expose a ref property? What's wrong with having to say $foo.ref ? Or why not go further and collapse the two into a single Ref delegate . What advantage is there for users to have to think about both boxes and refs when this distinction isn't strictly necessary?

Huh, I thought I had addressed this. The intent is that Box is for creating storage, and Ref is about referring to something that's either directly in a Box, formed through some other get / set pair (say, a computed value), or derived via key path from another Ref thing.

@anandabits

On a design front, delegateValue breaks out-of-line initialization. I think this is a problem and may indicate that we could find a better design for the feature itself and / or the delegates that might consider using it.

I liked your idea of doing Definite Initialization for the $ property based on init(initialDelegateValue:). Haven't had time to implement it yet, but it seems like a reasonable addition here.

@anandabits

If there is no meaningful API for users of a delegate other than value there is no reason to have $foo available at all. One direction I suggested we might consider is not even synthesizing a $foo backing storage if the delegate does not implement delegateValue . This would require delegates to opt-in to having a visible backing storage. The flaw with this design, as with the proposed design of delegateValue , is that it breaks out-of-line initialization.

Alternatively, one could make the $foo private in such cases. That gives you direct initialization and hides it from the outside world.

@anandabits

One interesting idea that came up late in the discussion and didn't receive much attention is to not expose the backing storage via $foo at all. Instead, relevant API would be available directly on the delegating property with `$-prefixed identifiers. This direction should be explored further. It would require further refinement but may be a better user-facing presentation of the delegate's behavior. One reason we should consider this direction is that autocomplete could support it, exposing the delegate's API in the place programmers would prefer to see it.

I'm fairly strongly against this direction, because delegate types are normal types. The "weirdness" should be in accessing the backing storage of the property that has a delegate; once you have that value, it's just a normal value of the delegate type.

FWIW, autocomplete can support this design, too, by inserting the '$' earlier. There's some precedent here with insertion of ? in someOptional.<completion shows members of the wrapped type>.

@anandabits

I believe the compiler is smart enough to be able to distinguish initialization from mutating assignment. Perhaps we should consider syntax that is only available for initialization and not otherwise available for reads and writes.

It is smart enough to do that through init(initialValue:). As mentioned above, it could do the same for an init(initialDelegateValue:).

Doug