<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="">Very interesting alternative!</div><div class=""><br class=""></div><div class="">I think my preferred implementation is to just add these capabilities to protocols directly, as I guess I just don’t see why we need to introduce a separate mixin type. Providing implementation directly within a protocol is definitely something I’d like in general; while extensions can be a nice way to structure complex protocols and types, sometimes simple cases just don’t really need them IMO, so that’d be nice as a general capability, not just for mixins.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><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" 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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>