<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="">Generally a -1 here. We have to be very careful.<div class=""><br class=""></div><div class="">Take Java as a worst case example; very object is hashable and it makes hashability almost meaningless as a constraint. Did the object actually implement a hash function appropriate to itself or is it relying on the default implementation? Any mechanism using hashability is at best fragile. This can get particularly difficult when the hashing usage of the class is behind an api and the class implementer has to understand that - despite not being required by the compiler - they need to provide an acceptable override of the hashing mechanism.</div><div class=""><br class=""></div><div class="">Java’s default hash function will only succeed against the exact same instance and this was probably chosen because it is very conservative and has no performance implications. But it is almost always not what a object that actually requires to be hashable will want.</div><div class=""><br class=""></div><div class="">So it comes down to the default implementation and I would argue that it might be impossible to provide a default implementation good enough particularly when you consider performance. The alternative to Java’s conservative same-instance hashability is some kind of memberwise implementation which could silently become a very expensive calculation (maybe unnecessarily so and even then might not accurately represent the hashablity/equality of the instance).</div><div class=""><br class=""></div><div class="">I think there could be some potential to provide a way to annotate a type to indicate what members should make up the hash/equality (and if they are all immutable, the hash could be pre-computed on instantiation) to avoid having to write boilerplate but it shouldn’t be an innate feature every type.</div><div class=""><br class=""></div><div class="">-Simon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 9 Mar 2016, at 5:51 AM, Step C 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class="">I find it valuable to think explicitly about what equality means for my types, though not so valuable to write a bunch of boilerplate to support it. Derivable or automatic conformances might also carry us further towards users being able to provide their own automagic conformances. </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">- Class references can be considered equal if they refer to the same instance,</span></blockquote></div><div class="">With opt-in conformance we could potentially have field comparison for classes too. I guess that would still need to be a customization point regardless as neither approach is always the right answer. </div><div class=""><br class="">On Mar 9, 2016, at 6:29 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">While I appreciate the idea behind the proposal, I think I’m a -1 to it. Java has required equality and hashable as part of its base Object class, but I frequently encountered classes that had very poor implementations for these, or never bothered to provide one; arguably they didn’t need to, which is fine, but it kind of went against the whole idea.</div><div class=""><br class=""></div><div class="">Swift has some pretty nifty features that also make this redundant, for example, I’ve been working on some ordered collection types; my natural inclination was to require that values be Comparable, however this actually limits the usefulness of the collection (or requires values to be wrapped somehow). Instead I decided to accept values of any type, and also take a closure (same as used to sort an array).</div><div class=""><br class=""></div><div class="">However, with generic constraints I can still provide a default closure for Comparable types like so:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Monaco" class="">// Sort Comparable elements in ascending order if no closure is provided.</font></div><div class=""><font face="Monaco" class="">extension OrderedCollection where Self.Generator.Element:Comparable {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init<S:SequenceType where S.Generator.Element == Generator.Element>(elements:S) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.init(isOrderedBefore: { $0 < $1 }, elements: elements)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">(the same feature also lets me implement ArrayLiteralConvertible for Comparable arrays, though I have to provide a default initialiser producing a fatal error for the rest)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">It’s a bit of a weird thing to get your head around at first, but you can solve a lot of problems in a similar way, without having to place overly strict requirements on the types that you can accept, removing the need for all types to conform to anything.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 9 Mar 2016, at 08:30, Austin Zheng 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">As Brent pointed out, adding this sort of support opens a whole can of worms. Large parts of the standard library would silently become unsound.<div class=""><br class=""></div><div class="">As well, in my experience people who have had trouble using (e.g.) Equatable with heterogeneous collections are often trying to do type-unsound things. Maybe Swift should support a separate notion of heterogenous equality for comparisons between Equatable types (and one of the POP WWDC talks actually sketched out an outline of how this might be done), but that's different from making Equatable universal. In addition, I think Swift 3's proposed support for conditional protocol conformance will make creating principled heterogeneous collections easier, which should ease some of the burden.<div class=""><br class=""></div><div class="">Best,</div><div class="">Austin<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 12:17 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">On 08 Mar 2016, at 23:15, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I would prefer Equatable and Hashable to remain opt-in, and for us to add better support for automatic deriving of implementation.</div></div></blockquote><br class=""><div class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">On 08 Mar 2016, at 23:57, Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></span></font></div><blockquote type="cite" class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I completely agree with Austin here. Automatic derivation (perhaps through the same mechanisms Joe is talking about) would be a nice enhancement, but I find it refreshing and advantageous for simple value types to have very little automatic behavior.</span></font></div></blockquote><br class=""></div><div class="">Pedantically I agree with both of you, but from a very pragmatic point of you, I think it's very important to point out what Joe said about how this could reduce one of the most frustrating aspects of Swift, when people work with heterogeneous arrays and try to conform to Equatable:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">that would solve many of the common problems people currently have trying to work with heterogeneous containers.</span></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">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=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<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></blockquote></div><br class=""></div></body></html>