> On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > This is nice. Thanks for taking the time to write it up. I do have some > concerns/questions: > > 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. To spell out the rules of Codable conformance clearly, for reference:
> 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. 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. [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.] > Furthermore, does Codable ignore computed properties? If not, then neither > should Equatable and Hashable. 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). [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.] > 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. 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. It would be helpful to document these rules somewhere, so noted. > On Mon, May 15, 2017 at 17:21 Tony Allevato via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Yes—the PR of the proposal is here: > https://github.com/apple/swift-evolution/pull/706 > <https://github.com/apple/swift-evolution/pull/706> > > 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.) > > > On Mon, May 15, 2017 at 3:18 PM Andrew Bennett <cac...@gmail.com > <mailto:cac...@gmail.com>> wrote: > Nice work Tony! Is this proposal up for PR on swift-evolution as well? > > On Tue, 16 May 2017 at 7:30 am, Tony Allevato <tony.allev...@gmail.com > <mailto:tony.allev...@gmail.com>> wrote: > 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: > https://github.com/apple/swift/pull/9619 > <https://github.com/apple/swift/pull/9619> > > Hopefully there's still enough time to get the proposal reviewed, make any > changes needed, and get this into Swift 4! > > > On Tue, May 9, 2017 at 10:27 PM Brent Royal-Gordon <br...@architechies.com > <mailto:br...@architechies.com>> wrote: >> On May 9, 2017, at 3:53 PM, Tony Allevato via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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. :) > > > 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. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
