<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 5, 2017, at 10:45 AM, Tony Allevato 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="">Thanks for your feedback, everybody!</div></div></blockquote><div><br class=""></div>Thanks for continuing to drive this forward!</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">I've updated the <a href="https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad" class="">gist</a> to reflect what seems to be a consensus here:</div><div class=""><br class=""></div><div class="">* Derived conformances are now opt-in (this makes the recursive case *much* cleaner, and the complexity involved in that section has been completely removed)</div></div></div></blockquote><div><br class=""></div><div>Can the opt-in conformance be declared in an extension? If so, can the extension be in a different module than the original declaration? If so, do you intend any restrictions, such as requiring all members of the type declared in a different module to be public? My initial thought is that this should be possible as long as all members are visible.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">* Classes are supported now as well</div><div class=""><br class=""></div><div class="">Please take a look at the updated version and let me know if there are any concerns! If folks like it, I'll prepare a pull request.</div></div></div></blockquote><div><br class=""></div><div>Will the synthesis for classes dispatch through a non-final method which is expected to be overridden by subclasses? You don’t explicitly state this but it seems implied. If so, what if the subclass requires a custom implementation? This would require the signature of the non-final method to be part of the synthesis contract.</div><div><br class=""></div><div>Supporting non-final classes introduces enough complexity (especially when multiple modules are involved). I would hate to see it get sidetracked in discussions regarding non-final classes and miss the Swift 4 window because of that. Given the limited time left for Swift 4 it might be better to keep the initial proposal simpler and consider a followup in the Swift 5 timeframe to build on the initial proposal.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><span class="m_1203078577276602968gmail-">On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon <span dir="ltr" class=""><<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>></span> wrote:</span><div class="gmail_extra"><div class="gmail_quote"><span class="m_1203078577276602968gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I would think only final classes could participate in this, since a subclassable class would need to allow subclasses to override equality, and you can't override a static `==` operator method.</div></div></blockquote><div class=""><br class=""></div></span><div class="">I work so rarely with classes that I'm embarrassed to have to ask this question: can classes not satisfy Equatable with a `public class func ==`?</div></div></div></div></blockquote></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""></div></blockquote><div class=""><br class=""></div><div class="">Currently:</div><div class=""><br class=""></div><div class=""><div class=""><font face="monospace, monospace" class="">class C: Equatable {</font></div><div class=""><font face="monospace, monospace" class=""> class func == (lhs: C, rhs: C) -> Bool {</font></div><div class=""><font face="monospace, monospace" class=""> return lhs === rhs</font></div><div class=""><font face="monospace, monospace" class=""> }</font></div><div class=""><font face="monospace, monospace" class="">}</font></div></div><div class=""><br class=""></div><div class="">Yields an error, “Operator '==' declared in non-final class 'C' must be 'final'”.</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Nevin</div></div></div></div>
_______________________________________________<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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></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>