<div dir="ltr">I now have 4 votes &quot;for&quot; separating this new entity from protocols. Proposal changed.<div>I tried to solve the aforementioned issues except the last one, which essentially compares mixins to abstract classes.</div><div>More &quot;bug reports&quot; welcome!</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-28 16:47 GMT+03:00 Patrick R. Gili <span dir="ltr">&lt;<a href="mailto:gili.patrick.r@gili-labs.com" target="_blank">gili.patrick.r@gili-labs.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I see many problems with this proposal:</div><div><br></div><div>- The proposal doesn&#39;t provide a compelling example to change Swift.</div><div><br></div><div>- The proposal doesn&#39;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&#39;t support the notion of mix-ins in Swift. Instance variables defined by a mix-in cause many problems, and hence I don&#39;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><div class="h5"><div><br>On Feb 27, 2016, at 8:10 AM, Антон Жилин via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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">&lt;<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>&gt;</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><div>On 27 Feb 2016, at 09:59, Антон Жилин via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br></div></div><div><div><div><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 &quot;alternatives&quot;.</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" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>