[swift-evolution] Equatability for enums with associated values

[Karl Wagner]

> On 13 Jan 2017, at 23:02, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 13, 2017, at 1:10 PM, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> That seems pretty close to Rust’s derive. Why not invent a similar syntax in Swift? Otherwise it will make us look through all the sources to make sure deriving is used.
>> 
>> enum Option: @derive Equatable {
>>    ...
>> }
> 
> My feeling on this is that it feels strange to treat compiler-provided default implementations as different from library-provided default implementations. If the library provides a protocol extension with an appropriate default implementation for your type, you get it without any work on your part. While the Equatable/Hashable/Comparable conformance would most practically compiler generated today, you could imagine a far future version of Swift having sufficiently powerful generic type traits to do this in the library.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

It would be helpful for synthesised RawRep conformance. The inheritance-like syntax we have now is awful - it makes people think that RawRepresentable is some kind of magic protocol that will allow special compiler jango to happen.

You could see why they think that. This looks very much like the enum is going to *be* an Int32:

enum Something: Int32 {
    case oneThing = 36
    case anotherThing = 42
}

This is also one of the icky parts to allowing tuples of integer/string literals (something people ask for quite a lot). It would look like you’re deriving your enum from a non-nominal type:

enum Something: (Int32, Int32) {
    case oneThing = (3, 12)
    case anotherThing = (5, 9)
}

Getting back to the topic: we should do this. We do it for plain enums. We do it for tuples of Equatables. No reason we can’t do it for enums whose payloads are Equatable tuples.

As for the broader picture on enums, my opinion is that it could be addressed together with extending tuples and allowing them to conform to protocols. In both cases we are expressing a conditional conformance for all (tuples/enums) whose payload types match a set of constraints to conform to a protocol. They would both require syntax to bind flexible numbers of (tuple elements/enum cases) using some type constraints.


- Karl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170116/7db62663/attachment.html>