<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 13 Jan 2017, at 23:02, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jan 13, 2017, at 1:10 PM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">enum Option: @derive Equatable {<br class=""> ...<br class="">}<br class=""></blockquote><br class="">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.<br class=""><br class="">-Joe<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">You could see why they think that. This looks very much like the enum is going to *be* an Int32:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier" class="">enum Something: Int32 {</font></div><div class=""><font face="Courier" class=""> case oneThing = 36</font></div><div class=""><font face="Courier" class=""> case anotherThing = 42</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><font face="Courier" class=""><br class=""></font></div></blockquote>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:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Courier" class="">enum Something: (Int32, Int32) {</font></div></div><div class=""><div class=""><font face="Courier" class=""> case oneThing = (3, 12)</font></div></div><div class=""><div class=""><font face="Courier" class=""> case anotherThing = (5, 9)</font></div></div><div class=""><div class=""><font face="Courier" class="">}</font></div></div><div class=""><font face="Courier" class=""><br class=""></font></div></blockquote>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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""></div></div></body></html>