<div dir="ltr">Is there any mechanism to mark a property as not participating in derived conformances? One instance might be that I have a memoization/cache related property that is stored but should not be considered when equating two instances.<div><br></div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 3:51 AM, Xiaodi Wu via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Mon, May 15, 2017 at 7:18 PM, Tony Allevato <span dir="ltr"><<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Mon, May 15, 2017 at 4:38 PM Itai Ferber <<a href="mailto:iferber@apple.com" target="_blank">iferber@apple.com</a>> wrote:<br></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;line-break:after-white-space"><div><blockquote type="cite"><div>On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-864605982813146071m_6988024763543182915m_-5218112165122467932Apple-interchange-newline"><div>This is nice. Thanks for taking the time to write it up. I do have some concerns/questions:<br><br>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></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>To spell out the rules of Codable conformance clearly, for reference:</div><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>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></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>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></blockquote><div><br></div></span><div>To the best of my knowledge, the Equatable/Hashable synthesis I added uses the same rules as Codable, since I based my implementation on it.</div><div><br></div><div>This is slightly different than what we initially discussed in this thread, which was that we should not support synthesized conformance in extensions in other modules. But after implementing it, my feeling is that if it falls out naturally and prohibiting it would be more work, then we shouldn't do that unless we have good reason to, and we should do it consistently with other derivations. So I'm using the same model.</div><span><div><br></div><div><br></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;line-break:after-white-space"><div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>Furthermore, does Codable ignore computed properties? If not, then neither should Equatable and Hashable.</div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><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.getStoredProp<wbr>erties` (getStoredProperties(/*skipIna<wbr>ccessible=*/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></div></div></blockquote><div><br></div></span><div>Yes, I'm using the same getStoredProperties call to find the struct members to apply it to (thanks Itai for the early pointers!), so Eq/Hash should be synthesized for structs under the same conditions as Codable.</div><span><div> </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;line-break:after-white-space"><div><br><blockquote type="cite"><div>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></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><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></div></blockquote><div><br></div></span><div>The concern that changing a stored property to a computed property would silently change the behavior of Eq/Hash is definitely something we should be aware of and we should see if it's something that people run into frequently once they start using the synthesis. Nothing obvious comes to mind as a way of preventing or warning about it, though—I'd have to think more on it.</div><span><div><br></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;line-break:after-white-space"><div><div><br></div><div>It would be helpful to document these rules somewhere, so noted.</div></div></div></blockquote><div><br></div></span><div>+1.</div></div></div></blockquote><div><br></div></span><div>Highly agree with all your responses; also, delighted to hear that the implementation work has fallen into place so naturally.</div><div><br></div><div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>