<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 15, 2017, at 4:03 PM, Xiaodi Wu 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="">This is nice. Thanks for taking the time to write it up. I do have some concerns/questions:<br class=""><br class="">Do the rules you spell out align with those for Codable? I think it is very important that these are paralleled as closely as possible, and that any deviations are explicitly called out in the text with reasoning as to why it must deviate. Knowing when something is synthesized is difficult enough with one set of rules--two is certainly one too many.<br class=""></div></blockquote>To spell out the rules of Codable conformance clearly, for reference:</div><div><br class=""><blockquote type="cite" class=""><div class="">For example, is it permitted to extend a type in the same module in order to obtain synthesized Codable conformance? How about for a type in a different module? The same rules should then apply for Equatable and Hashable synthesis.<br class=""></div></blockquote>Yes, Codable conformance can be added in an extension both intra-module, and inter-module (i.e. you can add Codable conformance via extensions in your own module, or to types in other modules). If there is a situation where this is not possible, that’s likely a bug.</div><div>[For reference, it is actually easier to allow this than to prevent it. I had to do very little extra work to support this because of how this is organized in the compiler.]</div><div><br class=""><blockquote type="cite" class=""><div class="">Furthermore, does Codable ignore computed properties? If not, then neither should Equatable and Hashable.</div></blockquote><div>Yes. Derived conformance for Codable ignores all computed properties (including lazy properties and their associated storage). This is also some relatively easy default behavior; you can iterate all properties matching this requirement via `NominalTypeDecl.getStoredProperties` (getStoredProperties(/*skipInaccessible=*/true) will skip the storage associated with lazy vars).</div><div>[The thought process here is that accessing computed vars (and more so lazy vars) will generally have side effects. We don’t want to trigger side effects on encoding/checking for equality/hashing, and in general, those types of properties will not affect equality/hash value/encoded representation.]</div><br class=""><blockquote type="cite" class=""><div class="">There are also some complicated rules with generics, if I recall, that may force something to be a computed property. It would be worth exploring if such rules make ignoring computed properties counterintuitive. For instance, if a user has to redesign the type, changing a stored property to a computed property just to satisfy certain rules of the language, and all of a sudden the definition of equality has silently changed as a consequence, then that could end up being very hard to debug. If we find that this is a plausible issue, then it might be worth considering refusing to synthesize Equatable conformance for a type with any computed properties--obviously limiting, but better limiting than surprising. To be clear, I'm not suggesting that we do make this limitation, just that I don't know that the consequences have been adequately explored for not including computed properties.<br class=""></div></blockquote><div>I’m not sure about this — someone else will have to weigh in. I don’t think I’ve ever encountered a situation like this while working on Codable. That being said, if there’s a limiting factor here that we encounter, we should absolutely be consistent between all implementations of derived conformance. </div><div><br class=""></div><div>It would be helpful to document these rules somewhere, so noted.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, May 15, 2017 at 17:21 Tony Allevato 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="">Yes—the PR of the proposal is here: <a href="https://github.com/apple/swift-evolution/pull/706" target="_blank" class="">https://github.com/apple/swift-evolution/pull/706</a><div class=""><br class=""></div><div class="">It needs to be updated slightly—I'll remove the references to the "multiplicative hash function" recommendation because I ended up using the existing _mixInt and xor, which is how the standard library implements its Collection hashValues. (The proposal probably really doesn't need to state anything about the hash function used, and its entirely an implementation detail.)</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, May 15, 2017 at 3:18 PM Andrew Bennett <<a href="mailto:cacoyi@gmail.com" target="_blank" class="">cacoyi@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="">Nice work Tony! Is this proposal up for PR on swift-evolution as well?</div></div><div class=""><div class=""><br class=""><div class="gmail_quote"><div class="">On Tue, 16 May 2017 at 7:30 am, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank" class="">tony.allevato@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Just to update everyone on the thread—it took a little longer than I'd hoped to get the kinks out, but I finally have the implementation up as a PR: <a href="https://github.com/apple/swift/pull/9619" target="_blank" class="">https://github.com/apple/swift/pull/9619</a><div class=""><br class=""></div><div class="">Hopefully there's still enough time to get the proposal reviewed, make any changes needed, and get this into Swift 4!</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div class="">On Tue, May 9, 2017 at 10:27 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank" class="">brent@architechies.com</a>> wrote:<br class=""></div><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=""><blockquote type="cite" class=""><div class="">On May 9, 2017, at 3:53 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7634931506526190142m_5760772590623056947m_-3114140352773685947m_5619269197906473925m_-7922117415000113549Apple-interchange-newline"><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Likewise, proposing a new public addition to the standard library would inspire far more design discussion than I believe we have time for if we want this to make Swift 4. :)</span></div></blockquote></div><div class=""><br class=""></div></div><div style="word-wrap:break-word" class=""><div class="">Agreed. What I would do here is add an `_combineHashes` function (or `Hashable` extension method, or whatever is most convenient) to the standard library in Swift 4, have your compiler magic feature use it, and defer the name-and-interface discussion until Swift 5.</div></div><div style="word-wrap:break-word" class=""><br class=""><div class="">
<span class="m_-7634931506526190142m_5760772590623056947m_-3114140352773685947m_5619269197906473925m_-7922117415000113549Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-variant-east-asian: normal; font-variant-position: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div class=""><div style="font-size:12px" class="">-- </div><div style="font-size:12px" class="">Brent Royal-Gordon</div><div style="font-size:12px" class="">Architechies</div></div></span>
</div>
<br class=""></div></blockquote></div>
</blockquote></div></div></div>
</blockquote></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>
_______________________________________________<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>