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

[T.J. Usiyan]

It isn't explicit that you are synthesizing code. This is especially true
because we can still declare conformance on one declaration/extension and
implement in another. You could even conform in another file. This isn't
generally good form but it is valid code and it is even, in some cases,
somewhat reasonable.(You might have moved an extension or it might be
relevant to some other bit of code somewhere but you want the conformance
visible on the declaration because it is of prime importance.

On Sat, May 28, 2016 at 7:43 PM, Pedro Vieira via swift-evolution <
swift-evolution at swift.org> wrote:

> I really think this would be a great addition to Swift. Although, I don't
> see the need to use a new keyword `deriving` for this feature.
> The following would be enough:
>
> struct Foo: Equatable, Hashable {
>   ...
> }
>
> It's explicit and it uses features already in the language. With this, the
> compiler would generate all the functions needed for `Foo` to conform to
> `Equatable` and `Hashable` and, in case the developer wants custom behavior
> on any of those functions, he/she could just write it from scratch and the
> compiler would use it over the generated one.
>
> Michael Peternell via swift-evolution <swift-evolution at swift.org>
> escreveu no dia quinta, 26/05/2016 às 10:58:
>
>> Can we just copy&paste the solution from Haskell instead of creating our
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable`
>> would become
>>
>> struct Polygon deriving Equatable, Hashable {
>>     ...
>> }
>>
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason),
>> you can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any
>> new incompatibilities. For example, `CustomStringConvertible` could be
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape<T> deriving
>> Equatable` will make every `Shape<X>` equatable if `X` is equatable. But if
>> `X` is not equatable, `Shape<X>` can be used as well. (Unless `X` is not
>> used, in which case every `Shape<T>` would be equatable. Unless something
>> in the definition of `Shape` makes deriving `Equatable` impossible => this
>> produces an error.)
>> - It is proven to work in production.
>>
>> -Michael
>>
>
> Pedro Vieira
> http://pedrovieira.me
> --
> Pedro Vieira
> http://pedrovieira.me
>
> _______________________________________________
> 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/20160529/0d3e7dba/attachment.html>