<div dir="ltr"><div>On "traits vs mixins",<br></div><div>I tend to agree with Patrick Gili that probably the most important difference between traits and mixins is that mixins define state. This article agrees: <a href="http://matthijshollemans.com/2015/07/22/mixins-and-traits-in-swift-2/">http://matthijshollemans.com/2015/07/22/mixins-and-traits-in-swift-2/</a></div><div><br></div><div>On initializers,</div><div>Initializers really only make sense on fully defined types. That's why I disallowed implicit initializer inheritance. But I believe that "helpers", which know how to initialize their part of state, can be useful.</div><div><br></div><div>On mixin conflicts resolving,</div><div>I agree that this question should be solved not in "future directions", but within the proposal itself. "Merge members" and "keep copies for both super mixins" are equal alternate options.</div><div>We need to decide on syntax. I also don't fully understand how it should work, question below.</div><div><br></div><div>A special thanks ot Thorsten Seitz for opening my eyes on problems in Swift type system. I agree with "dream" part completely. But I'm afraid, that already can't be changed.</div><div><br></div><div>New set of questions:</div><div><br></div><div>1. Can a mixin contain uninitialized state, unlike fully defined types? Example:</div><div><br></div><div>mixin A { var x: Int }</div><div>struct B: A { init(x: Int) { self.x = x } }</div><div><br></div><div>2. What should be syntax for conflict resolution? I will use the following in this post:</div><div><br></div><div>var x = A.x</div><div>func f() = A.f</div><div><br></div><div>The intent here should be to use existing Swift constructs.</div><div><br></div><div>3. If we decide to keep two copies in a conflict, do we need to rename all members, or can we rename selectively? Example:</div><div><br></div><div><div>mixin A {</div><div> var x: Int = 0</div> func show() { print(x) }<div>}</div><div>mixin B {</div><div> var x: Int = 1</div> func show() { print(x) }<div>}</div><div>struct S: A, B {</div><div> var y = A.x</div><div> var z = B.x</div><div> // nothing touching show()</div><div>}</div><div>let s = S()</div><div>s.show() //=> 0 or 1?</div></div><div><br></div><div>This example could also be formulated for problem A -> (B,C) -> D</div><div><br></div><div>4. Should we allow for arbitrary renaming of members in subtypes, not only in conflicts?</div><div><br></div><div>5. Should we allow conflicting inherited members until usage or throw an error immediately?</div><div><br></div><div><div>mixin A { var x: Int = 0 }</div><div>mixin B { var x: Int = 1 }</div><div>struct C: A, B { func show() { print(A.x); print(B.x) } }</div><div>let c = C() // error??</div><div>C().show() //=> 01</div><div>C().x // error: "x is a conflicting member in C, cannot be called here"</div></div><div>C().A.x // syntax error</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-02 8:37 GMT+03:00 Thorsten Seitz <span dir="ltr"><<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Am 02.03.2016 um 02:00 schrieb Brian Pratt <<a href="mailto:brian@pratt.io">brian@pratt.io</a>>:<br>
><br>
> If something *is* both an A and a B, it needs to act like (and speak the same language of) an A or a B *all* of the time.<br>
<br>
</span>Yes, that is exactly the point of Eiffel-style-multiple inheritance.<br>
<span class=""><br>
> Beyond this, I think it's going to be extremely complex managing compile-time type constraints with renames in place. Let's say I have a class C that inherits from bases A and B, which implement protocol P and Q respectively, and there's a naming collision. Functions that expect Ps or Qs will have to know about the renaming of conflicts from the combination of A+B?<br>
<br>
</span>No, functions that expect Ps or Qs will talk the language of P and Q. They don't have to know about renaming (that's the whole point which is only possible in statically typed languages).<br>
Functions that expect C will have to know about renaming. They will talk the language of C.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Thorsten </font></span></blockquote></div><br></div>