<div dir="ltr"><div>I understand now where some misunderstandment comes from. I haven't really used any languages with traits, but looking at the definition, my proposal surely talks about "traits with state".</div>I currently don't suggest any ways to resolve these conflicts. Adding it to future directions for now.<div>protocol<A, B> in Swift is the same as protocol InlineProtocol : A, B { }</div><div><div><div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-28 4:17 GMT+03:00 Howard Lovatt <span dir="ltr"><<a href="mailto:howard.lovatt@gmail.com" target="_blank">howard.lovatt@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the proposal but would suggest you rename it Trait and not Mixin, since you proposal has Trait and not Mixin behaviour. The difference is that the order of inheritance is not important with Traits but is with Mixins, EG:<div><br></div><div> <font size="2"><span style="background-color:rgba(255,255,255,0)"><span>protocol</span> A { let msg = "A" }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> <span>protocol</span> B { let msg = "B" }</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> struct MixinAB: A, B {}</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> MixinAB().msg // B</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> </span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> Whereas</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> struct MixinBA: B, A {}</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> MixinBA().msg // A</span></font></div><div><br></div><div>With traits the order is not important, and has to be resolved by the programmer when a conflict arises:</div><div><br></div><div> <font size="2"><span style="background-color:rgba(255,255,255,0)">struct ErrorAB: A, B {} // An error because there are two `msg`s.</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">You have to do:</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> struct TraitAB: A, B { // Could be B, A - makes no difference</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> let msg = A.msg // Select A's definition, could be `= B.msg`, could be `= 3` (i.e. any valid Swift)</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"> }</span></font></div><div><br></div><div>As an aside I don't get what you mean by your example:</div><div><pre style="overflow:auto;margin-top:0px;margin-bottom:0px;line-height:1.45;padding:16px;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;word-break:normal"><span style="white-space:normal;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif">protocol</span><span style="white-space:normal;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif"><</span><span style="white-space:normal;background-color:rgba(255,255,255,0);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:medium">A, B</span><span style="white-space:normal;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif">></span><span style="white-space:normal;background-color:rgba(255,255,255,0);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:medium"> </span><span style="white-space:normal;font-family:'Helvetica Neue',Helvetica,Arial,sans-serif">// error</span></pre>Protocols cannot be generic!</div><div><div><div><br>On Sunday, 28 February 2016, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>0. Please read the whole proposal and this whole message before replying.<br>
<br>
1.<br>
> In short words, protocol will became a sort of class and no longer a true kind of contract to conform to.<br>
<br>
There is an option to introduce "mixin" keyword:<br>
mixin M {<br>
var storage: Int = 0<br>
}<br>
It won't cause confusion with today's protocols.<br>
For difference from classes, see under 3.<br>
<br>
2.<br>
> What about compatibility with Objective C ?<br>
<br>
Protocols cannot inherit from classes, including NSObject.<br>
[Warning: IMO ahead]<br>
But I personally think that we should move from abstract classes in Obj-C, where possible. Actually, all classes in Obj-C can be instantiated, so I consider this a bad abstraction.<br>
<br>
3.<br>
> (see David's message)<br>
Firstly, what you've shown is not a diamond problem. No dequate programming language would allow you to do what you've shown. Secondly, please read the whole proposal, as I specifically addressed the issue there.<br>
<br>
Now, to difference from classes.<br>
The largest difference between classes and mixins comes in inheritance. We can allow multiple inheritance, because we can solve diamond problem with mixins.<br>
Let's take the example from my proposal:<br>
<br>
protocol A { var x: Int = 1 }<br>
protocol B: A { }<br>
protocol C: A { }<br>
struct D : B, C { }<br>
<br>
What really happens here is the following:<br>
<br>
protocol ASelf { var x: Int = 1 }<br>
protocol BSelf { }<br>
protocol CSelf { }<br>
struct D : ASelf, BSelf, CSelf { }<br>
<br>
We can do this, because mixins are statically dispatched. The compiler will enumerate all included mixins and mix in only one version of each.<br>
I said statically dispatched, but in Swift, compiler can automatically create wrappers with necessary closures inside if we need dynamic dispatch for protocols, so that is not a real concern.<br>
Diamond problem is solved the same way in Python and Ruby, so I'm not inventing something new here.<br>
Mixins tend to "mix in behaviours". Let's take an example usage of diamond pattern:<br>
<br>
protocol SignalSender {<br>
private var slots: [String: [() -> ()]] = []<br>
func connect(signal: String, to slot: () -> ()) { ... }<br>
func fire(signal: String) { ... }<br>
}<br>
protocol A : SignalSender {<br>
// Use signal functionality<br>
}<br>
protocol B : SignalSender {<br>
// Use signal functionality<br>
}<br>
struct C : A, B { }<br>
<br>
A and B both use a single SignalSender, incorporated within final object. If SignalSender supports its invariants through incapsulation, nothing will ever break them. If it doesn't, then, well, this mixin is not perfectly suited for multiple inheritance.<br>
<br>
If you have reached this far, thank you!<br></div></div><span>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></blockquote></div><span><font color="#888888"><br><br>-- <br>-- Howard.<br>
</font></span></blockquote></div><br></div></div></div></div></div>