Is there no one that thinks it's sufficient if users can create a tuple from a list of properties and reuse tuple equality and hash?
Is there no one that thinks it's sufficient if the system were to supply a named function for comparing two Any's for equality (with reference equality semantics for reference types, bit equality for value types) that users could use in their type's implementations of ==? Is there no one that thinks the opt-in mechanism should be a call to a system supplied function, instead of coming up with new keywords or opting in directly through the protocol? (Well I know there's at least one person that thinks the opt in mechanism should be by calling a function) -- Callionica On Mon, May 30, 2016 at 12:04 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > It seems that there are two groups here. 1) Group 1 wants Equatable (and > others) be derived automatically unless specifically overridden: similar to > auto-synthesis of properties in Objective-C. 2) The other group (Group 2) > wants Equatable (and others) be derived explicitly using a `deriving` > keyword (or something semantically equivalent). Unless I missed something, > there were no voices for keeping the status quo, and not introducing any > process to automatically derive these protocols. > > I think I chose an easy strategy when proposing the `deriving` keyword. > Haskell is a mature language, and "copying" a feature from them is usually > a safe choice. For each language feature, someone has to think through all > the implications of it; this is usually far from trivial. I argue that if I > take a feature from another language, someone has probably already thought > about all the pros and cons of different solutions. This is just a plea for > embracing precedent. > > There is one advantage of method 2 that (I think) hasn't been discussed so > far: when you declare a type `S`, and an `Equatable` instance is > automatically derived, there is no way to override that instance in another > module. With method 1, there is also no way to request that an `Equatable` > instance should *not* be generated. I think no one will vote for something > like `struct S @notderiving(Equateble,Hashable) { ... }`. > > Also, a `deriving` keyword is less magical than just automatically > deriving `Equatable` and `Hashable` instances. I think the language rules > should be as simple as possible, by default. If you want any kind of > special behavior, you have to ask for it: `deriving Equatable`, > `@IBOutlet`, `@NSManaged`. Furthermore, I think it is good that the > developer is aware that there is an "==" method somewhere, specifically for > this new type. The compiler should not arbitrarily create methods, because > someone may need them. Even if it is very likely that you will need them. > Just like in a coffee house, you are asked if you want a coffee, even if > you are visiting it every day. For example with Objective-C, I want each > developer to be aware of the difference between a property and an iVar, and > be aware of the connection between properties, methods, and > key-value-coding. The complexities of the language shouldn't be hidden > completely. > > Just my two cents.. > > -Michael > > _______________________________________________ > 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