[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Dec 21, 2015, at 5:22 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>>> I actually think that behavior instances should probably be private, and there should be no way to change that. Behaviors are inherently an implementation detail, and you should not be exposing them directly to users of your type. Instead, you should expose just the operations you expect to be needed through your own calls, which you can reimplement as needed.
>> 
>> I'm leaning in this direction too. The idea of exposing the behavior itself as a value seems wrong for almost any client. "foo.prop.reset()" is slightly nicer than "foo.resetProp()", but not if it conflicts with a 'reset' that's already on the property type. "foo.prop at behavior.reset()" certainly isn't an improvement.
> 
> I've been thinking about this more, and I think there's at least one exception: if you introduce a behavior that allows for arbitrary observers to watch a property (basically a KVO replacement), you want a standard way to access that functionality, rather than having to declare cover methods for everything. So maybe the visibility of the behavior should be controllable, but by the behavior itself, not the property it's applied to.

Yeah. There are behaviors where exporting the functionality is important, so I think we need to preserve the ability to make them public. In addition to `KVOable`, `resettable` also meets this criterion—there's no point in declaring a resettable property if clients can't reset it. Maybe visibility is a trait of the behavior, though, and not necessarily of the property declarations using it, since something like 'KVOable' is almost always something you want to publish, whereas `lazy` is almost always an implementation detail. However, I could see people wanting to also publish things like `lazy`, `copying`, or `synchronized` as documentation of semantics, even if they aren't directly useful as API.

-Joe