[swift-evolution] [Pitch] Property reflection

[Brent Royal-Gordon]

> This one is tricky.  I am generally be opposed to any way to get around access control.  But people are going to implement things like serialization using this which may require access to private properties.  I think we want to try to understand the consequences of different options and when in doubt decide in favor caution.

I had some thoughts about an alternate design based partially on access control concerns. Sketching roughly, it looks like this:

* There is a pseudo-property called, say, `properties` on every type (and perhaps on every instance). (Alternate designs are available, like an `inout`-returning pseudo-function. It doesn't really matter.)

* `properties` is a dictionary, or at least something very like a dictionary: you can look something up by key or iterate over the available keys. Its keys are strings, and its values are lens functions. These lens functions return type Any; their setters throw if you assign an incompatible type.

* The contents of `properties` are the properties visible *at the site where it is called*. That means calling `properties` in different places will give you different results. If you import a type from another module and then add properties in an `internal` extension, you'll see the other module's `public` properties plus your `internal` ones.

* You can pass your `properties` dictionary to other code; that effectively delegates your access to that other code. Thus, if your main class body passes its `property` dictionary to a serialization library, that library can access your private properties. If you pass it `inout`, then the library can modify your private properties.

* There is no opting in, but I *think* the compiler has enough information to figure out what goes into `properties` at the sites where it is used, so you only have to pay for it if and when you use it. I could be wrong, though—there may be something there that I'm missing.

-- 
Brent Royal-Gordon
Architechies