<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I see many problems with this proposal:</div><div><br></div><div>- The proposal doesn't provide a compelling example to change Swift.</div><div><br></div><div>- The proposal doesn't provide much detail. It glosses over the general concept.</div><div><br></div><div>- Protocols define a statement of conformance, not behavior. Adding instance variables and non-default methods is outside the scope of a protocol.</div><div><br></div><div>- However, the proposal does describe something closer to a mix-in. Given my experience with Ruby and mix-ins, I really can't support the notion of mix-ins in Swift. Instance variables defined by a mix-in cause many problems, and hence I don't see this proposal aligned with the direction of Swift.</div><div><br></div><div>-Patrick<br><br><div>Sent from my iPad Pro</div></div><div><br>On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I agree that adding those features to protocols is simpler. I switched the main suggestion and the alternative.</div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-27 15:03 GMT+03:00 Haravikk <span dir="ltr"><<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Very interesting alternative!</div><div><br></div><div>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><div><blockquote type="cite"><div><div class="h5"><div>On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">Some people opposed to Abstract Classes proposal (including myself) have said that mixins could solve the problem better.<div>So I prepaired a proposal draft to add stored properties to protocols. Here it is:</div><div><a href="https://gist.github.com/Anton3/f0550922c1be0fc5447c" target="_blank">https://gist.github.com/Anton3/f0550922c1be0fc5447c</a><br></div><div><br></div><div>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>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">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></div></blockquote></div><br></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>