<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 29, 2016, at 3:31 PM, Matthew Johnson 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=""><br class="">Sent from my iPad<br class=""><br class=""><blockquote type="cite" class="">On May 29, 2016, at 8:25 AM, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:<br class=""><br class=""><br class="">Should 'deriving' allows us to manually implement protocol requirements? For example<br class="">struct A : deriving Hashable {<br class=""> var hasValue : Int {...}<br class="">}<br class=""><br class="">Or there should be a compilation error in this case?<br class=""></blockquote><br class="">This should be an error. If you want to implement it manually your should use the usual conformance declaration syntax.<br class=""></div></div></blockquote><div><br class=""></div><div>Considering it can all be done without <i class="">deriving</i>, so I wager they will never add it </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">Right now I feel that if we can have auto-deriving by using current syntax for protocol conformance - we sholdn't introduce new keyword and new rules for this.<br class=""></blockquote><br class="">We've already covered the reasons why this is problematic. It's better to be explicit about the request for synthesized conformance.<br class=""><br class=""><blockquote type="cite" class="">The requirement to explicitly conform your type to protocol for auto-deriving is IMO reasonable compromise between separate 'deriving' decoration and implicit derivation(when your type is Hashable without any conformance to protocol, just if each property is Hashable).<br class=""><br class=""><blockquote type="cite" class="">On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:<br class=""><br class=""><br class="">Sent from my iPad<br class=""><br class="">On May 29, 2016, at 12:28 AM, Patrick Smith <<a href="mailto:pgwsmith@gmail.com" class="">pgwsmith@gmail.com</a><br class=""><<a href="mailto:pgwsmith@gmail.com" class="">mailto:pgwsmith@gmail.com</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Yeah I don’t see a problem. It’s the same way that protocol extensions<br class="">just work. Think of this automatic synthesis as a really flexible<br class="">protocol extension:<br class=""><br class="">extension Hashable where Members : Hashable {<br class=""> var hashValue : Int {<br class=""> return self.allMembers.reduce(^) // Or whatever combiner is best<br class=""> }<br class="">}<br class=""></blockquote><br class="">Protocol extensions require you to declare conformance before your type<br class="">receives their implementation and it must be identical for all do<br class="">conforming types.<br class=""><br class="">You should have to declare conformance to receive Equatable conformance and<br class="">synthesis. IMO it makes sense to do that with 'deriving' which makes it<br class="">clear that you are requesting synthesized rather than manual conformance.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class="">The problem with this is that it doesn’t differentiate between<br class="">synthesized and manual conformance. You won’t get error messages you<br class="">otherwise would when you intend to supply manual conformance. It is<br class="">also less clear to a reader of the code that the default, compiler<br class="">synthesized implementation is being generated.<br class=""></blockquote><br class="">I don’t think it’s reasonable to force the language down the path where<br class="">developers don’t have to be familiar with its features in order to use<br class="">them correctly. If types in Swift were to automatically gain Equatable<br class="">and Hashable conformances whenever they were used by something that<br class="">required them, that would be a core language feature, like type<br class="">inference, that even junior developers in the language would need to<br class="">know. Yet few (though not none) would insist that all types be manually<br class="">declared, despite otherwise not knowing when our type inference goes<br class="">wrong. It’s just a basic feature of the language that anyone using the<br class="">language should know about, otherwise it can bite them in the ass when<br class="">weird compiler errors start popping up.<br class="">Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast<br class="">majority of cases where my types are trivially equatable, I should just<br class="">be able to declare them as such and gain the compiler-synthesized ==. In<br class="">the cases where that’s not possible, the compiler can emit an error. And<br class="">in the cases where I want a custom == implementation I can provide it.<br class="">Requiring a new keyword and not making this feature as simple as<br class="">possible because the rare developer with a custom type who doesn’t want<br class="">the synthesized == they just said they did by declaring Equatable<br class="">conformance is an unnecessary defaulting to the rare case.<br class=""><br class=""><br class=""><br class="">Jon Shier<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></blockquote><br class=""><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=""><br class=""></blockquote></blockquote><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=""></body></html>