SE-0258: Property Wrappers (second review)

[Douglas_Gregor]

@anandabits

struct Foo {
    private var x = 42
}

struct Bar {
    var foo: Foo
}

Here, foo.x is not directly a property of Bar , but it is part of the storage area of Bar . Nevertheless, the implementation of Bar does not have access to it because access control allows the author of Bar to hide its properties if desired. I don’t see a wrapper type hiding its storage using wrapperValue as being materially different from this.

I don't see this as related at all, because it's not about whether Bar can reason about the storage of foo---it can't, because Foo is a distinct type. It's about whether Bar is able to create a Foo using the available API to initialize its own foo property.

@anandabits

Given how controversial wrapperValue has been I’m disappointed that something like this existed in the implementation but was not mentioned here.

Let's be clear: the stored property has to exist (it's fundamentally part of the compilation model), and it will be discoverable in metadata. When we get something like StoredPropertyIterable, you're going to be able to get key paths to these backing stored properties fairly easily, with names. Whatever name we choose for this backing storage, it's going to be exposed to the user at some point. My initial thought that it was an implementation detail---hence not documented explicitly---was factually incorrect, and (as I've noted before) wrong for real-world uses, led me to document this.

@anandabits

I stand by my prior review. If you feel strongly that a wrapper should not be able to hide the actual storage then I am opposed to wrapperValue . The final design provides no encapsulation tools for library authors. It only provides very magical syntactic sugar with a lot more potential for confusion than usual.

I emphasized the above sentence of yours, because I disagree with it. In the proposal, the backing storage property $$foo is always private---there is no mechanism to escalate its access, and I would oppose any change that did so. Having the stored property be private is encapsulation. It "hides" the stored property from outside of the type (and outside of the file) in any meaningful sense of the word. Obfuscating the name of the stored property (or pretending it has no name) doesn't give any more encapsulation tools to the library author, but it does take away their ability to reason about the stored properties of their own type.

In this proposal, the actual backing stored property is always private, which is Swift's strongest access-control mechanism to to achieve encapsulation. Property wrapper type authors can introduce wrapperValue to explicitly opt-in to having the $ property exposed further to provide wrapper-specific API via a custom type, providing per-wrapper control to cover the gamut of use cases.

I can understand the position that wrapperValue is too magic/unnecessary, even if I don't agree with it. However, I don't feel like the position that "having a name for the private stored property breaks encapsulation" is tenable.

Doug