[swift-evolution] [Draft] Mixins

David Scrève david.screve at dlta-studio.com
Sat Feb 27 14:30:43 CST 2016

	I have already considered adding store properties to protocols before proposing abstract classes, but there are some issues : 

1 - If protocols can have stored properties and default method implementation, how do you explain to newby the difference between a class and a protocol ? There is the same problem with Java 8 and interface which make learning to student really painfull….
In short words, protocol will became a sort of class and no longer a true kind of contract to conform to.

2 - What about compatibility with Objective C ?

3- more interesting problem : At the moment, multiple inheritance for protocol is allowed. When introducing store property in protocol, you introduce a major issue that C++ have : the diamond problem.

Example : 

protocol A {
	var value = 34

protocol B {
	var value = 23

class myClass : A, B {
    func init {
        print("Value  : \(value));

What should be print out ? how do you manage access to A.value and B.value ?

> Some people opposed to Abstract Classes proposal (including myself) have
> said that mixins could solve the problem better.
> So I prepaired a proposal draft to add stored properties to protocols. Here
> it is:
> https://gist.github.com/Anton3/f0550922c1be0fc5447c <https://gist.github.com/Anton3/f0550922c1be0fc5447c>
> P.S. I added a `mixin` keyword in the beginning, but we can opt to just
> extend protocols, which I mention in "alternatives".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/9d4d1db0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4233 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160227/9d4d1db0/attachment.p7s>

More information about the swift-evolution mailing list