[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Callionica (Swift)]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160530/f4e02d68/attachment.html>