<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Makes sense to me, and mixins are different enough conceptually from most protocols that having a separate keyword (or, more practically, a modifier keyword, like `mixin protocol`) might be desirable anyway.</div><div class=""><br class=""></div><div class="">The fact that protocols already come in two flavors — those that can act as types, and those that have associated types and therefore can only be used as generic constraints — sometimes feels confusing to me. Adding a third kind without any differentiation might not be a good idea.</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 27 Feb 2016, at 17:17, Trent Nadeau <<a href="mailto:tanadeau@gmail.com" class="">tanadeau@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">One limitation for "mixin" protocols would be that they can't be retroactively modeled, e.g. by having an extension for that protocol on a type outside of its file of definition. Allowing this would make the size of structs and classes unknowable to the compiler as an extension in another library could change the size of all instances.<div class=""><br class=""></div><div class="">That limitation is restrictive enough that having a special type of protocol and an associated keyword ("mixin") would probably be beneficial. The compiler could then easily check the intent of the protocol and ensure that a library doesn't break existing extensions just by adding a stored property. Only mixin protocols would have this capability. </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Feb 27, 2016 at 9:00 AM, Radosław Pietruszewski <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">This is compelling to me.</div><div class=""><br class=""></div><div class="">I haven’t put enough thought into it to make up my mind about it, but a mixin system would solve a problem I’m currently struggling with.</div><div class=""><br class=""></div><div class="">I’ve been working on cleaning up the codebase of my iOS/Mac app, and I’m trying to reduce duplication between the codebases. The problem is, there are things that aren’t easy to completely encapsulate into a separate, universal class — things that have bits and pieces in common, but different overall shape.</div><div class=""><br class=""></div><div class="">Perhaps I should encapsulate them anyway, add a level of indirection, inject dependencies… But a mixin is an abstraction that would allow me to extract common parts in an easier way.</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On 27 Feb 2016, at 10:59, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class="">Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.<div class="">So I prepaired a proposal draft to add stored properties to protocols. Here it is:</div><div class=""><a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank" class="">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a><br class=""></div><div class=""><br class=""></div><div class="">P.S. I added a `mixin` keyword in the beginning, but we can opt to just extend protocols, which I mention in "alternatives".</div></div></div></div><span class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Trent Nadeau</div>
</div>
</div></blockquote></div><br class=""></body></html>