> On May 28, 2016, at 8:43 PM, Pedro Vieira via swift-evolution
> <swift-evolution@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.
The problem with this is that it doesn’t differentiate between synthesized and
manual conformance. You won’t get error messages you otherwise would when you
intend to supply manual conformance. It is also less clear to a reader of the
code that the default, compiler synthesized implementation is being generated.
>
> Michael Peternell via swift-evolution <swift-evolution@swift.org
> <mailto:swift-evolution@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 <http://pedrovieira.me/>
> --
> Pedro Vieira
> http://pedrovieira.me
> <http://pedrovieira.me/>_______________________________________________
> 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
