[swift-evolution] [Proposal] Property behaviors

Michel Fortin michel.fortin at michelf.ca
Thu Dec 17 15:14:28 CST 2015


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
		}
	}

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.


-- 
Michel Fortin
michel.fortin at michelf.ca
https://michelf.ca



More information about the swift-evolution mailing list