I would think that:<div><br></div><div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">Example: A -> (B, C) -> D</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">B.init calls A.super.init(1)</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">C.init calls A.super.init(2)</span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">D.init calls B.super.init() and C.super.init()</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="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">is an error because there is one A and you have inited it twice. Just like calling super twice is an error currently. <span></span></span></font></div><br>On Wednesday, 27 April 2016, Антон Жилин <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, this is my proposal, and of course, I'm interested :)<div><br></div><div>I haven't read into the mentioned papers, but symmetric sum, asymmetric sum, alias, exclusion and derived operations form a solid basis for conflict resolution.</div><div>Mixins don't have all that tools and try to solve conflicts by being less strict at composition.</div><div>I agree that Swift, as a compiled language, would benefit from the former more.</div><div><div><br></div><div>In traits, I like how requirements and definitions are separated using requirement of protocol conformance.</div><div>It follows Uniform Access Principle: noone can require conformance to a trait.</div><div>Are there other benefits?</div><div><br></div><div>I believe there are situations where non-privateness of fields would help, see my two examples.</div><div>This can be overridden by adding a "proxy" computed property. But why is privateness needed?</div><div><br></div><div>Do traits have initializers? How do they work in diamond pattern?</div><div><br></div><div>Example: A -> (B, C) -> D</div><div>B.init calls A.super.init(1)</div><div>C.init calls A.super.init(2)</div><div>D.init calls B.super.init() and C.super.init()</div><div><br></div><div>Traits are flattened by default. Does it mean that A will be initialized twice? in what state will A be?</div><div><br></div><div>- Anton</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-27 2:50 GMT+03:00 Niall Young <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','niall@iinet.net.au');" target="_blank">niall@iinet.net.au</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 22 Apr 2016, Антон Жилин wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This feature has been previously discussed. Search for Mixins on swift-evolution archives.<br>
<br>
I believe it would help to read previous version of the proposal: <a href="https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md" rel="noreferrer" target="_blank">https://github.com/Anton3/swift-evolution/blob/mixins/proposals/NNNN-mixins.md</a><br>
</blockquote>
<br></span>
Cheers, already read through the thread - I'm more focused on implementing Traits, which I think is very similar but slightly different to what's been described in the thread to date.<br>
<br>
Is this your proposal? I'd love to give you some feedback, throw ideas back and forth if you're interested? If we can evolve the concept and implementation by Swift 4 that gives me enough time to brush up on C++ and start delving into Swift internals to see how best it could be done.<br>
<br>
Cheers,<br>
<br>
--<br>
Niall Young<br>
<a href="javascript:_e(%7B%7D,'cvml','niall@iinet.net.au');" target="_blank">niall@iinet.net.au</a></blockquote></div><br></div>
</blockquote></div><br><br>-- <br>-- Howard.<br>