[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Dec 17, 2015, at 1:14 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
> Le 17 déc. 2015 à 12:37, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> Beyond what we’ve baked into the language already, there’s a seemingly endless set of common property behaviors, including resetting, synchronized access, and various kinds of proxying, all begging for language attention to eliminate their boilerplate.
> 
> About synchronized access, it seems to me that it'd be advantageous if implementing subscript in a behaviour was optional. This way you can force access of a property through a synchronized block which will help avoid races:
> 
> 	var (synchronized) data: (x: Int, y: Int, z: Int)
> 
> 	func test() {
> 		data.synchronize { (data) in
> 			data.x += 1
> 			data.y += data.x
> 			data.z += data.y
> 		}
> 	}

Interesting. IIUC, if a behavior didn't supply a subscript operation, then the property could *only* be accessed through its behavior interface?

> As for combining behaviours... Someone should have to do the work of combining them properly by creating a new behaviour type for the combined behaviour. To make this easier syntactically, we could have a behaviour combination function that would create a combined behaviour type. That function could be overloaded to support only behaviours that are compatible with each other.
> 
> Overall, this looks very good. But there is almost nothing said about derived classes and overriding. I very often override a property just so I can add a `didSet` clause, and if `didChange` was implemented I'd use it too. I'd very much like if those property behaviours could be compatible with overriding (where it makes sense). The way I see it, the behaviour should be able tell the compiler whether the overriding accessor should either replace or be prepended or appended to the overridden closure from the base class, or if overriding is simply not allowed.

Yeah, composition of behaviors and overloading are two areas I'm still working through. Composition is tricky, since it's not scalable to require overloads for all possible M!/N! combinations of behaviors. Any decoupled composition behavior is going to have ordering problems too—lazy-before-synchronized and synchronized-before-lazy would both be accepted, but one would be broken (unless you could blacklist problematic combinations, which also seems like an exponential-order problem).

-Joe