I've been working on a proposal exploring how we can add pure functions to the language, but it still has some issues. There's the technical issue of deinitializers mainly, and the general problem of managing lots of annotations which I'm not sure can be solved adequately. Nevertheless, I thought it'd be worth sharing and discussing. Please have a look:
Then I realized this could serve as a more general model for concurrency if we reframe it a bit differently. So I took the first proposal and created a spinoff solely dedicated to concurrency. Apart from terminology changes, the two proposals are almost the same. This second one allows for more things to be done safely in a multithreaded environnement simply because getting rid of the requirements about value semantics and side effects allows more things to be labelled as concurrent.
It seems to me that, at least, cloning functions and CopyableObject overlap with some aspects of the Ownership Manifesto, IIRC.
Could this comparison be made explicit?
I don't think they overlap at all with the Ownership Manifesto actually.
cloning is just mutating in disguise; it means self is passed as inout. I was using mutating for this in earlier drafts, but mutating does not clearly say we can rebind the class reference whereas cloning clearly hints at the creation of a new object.
Anything the manifesto says about mutating applies to cloning too.
CopyableObject has no relation to the Copyable protocol mentioned in the manifesto. The manifesto's Copyable protocol (assuming it can apply to classes) would make the reference (pointer) copyable. We don't care about this here.
CopyableObject is simply a convenience for generating a correct copy-on-write implementation: instead of checking for the uniqueness of the reference yourself every time you write to a pure property and cloning the object in case it isn't unique, you can let the compiler do it for you by implementing this protocol. But you can still do it the hard way without CopyableObject if you want to.