[swift-evolution] Universal Equatability, Hashability, and Comparability

[T.J. Usiyan]

I am +1 on being able to opt in for a derived `hashValue` and an emphatic
+1 to the idea of being able to make functions conform to `Equatable` and
`Hashable` at all. I agree with the sentiment that it should still be opt
in, however.

TJ

On Wed, Mar 9, 2016 at 8:51 AM, Step C via swift-evolution <
swift-evolution at swift.org> wrote:

> 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.
>
> - Class references can be considered equal if they refer to the same
> instance,
>
> 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.
>
> On Mar 9, 2016, at 6:29 AM, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
> 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).
>
> However, with generic constraints I can still provide a default closure
> for Comparable types like so:
>
> // Sort Comparable elements in ascending order if no closure is provided.
> extension OrderedCollection where Self.Generator.Element:Comparable {
> init<S:SequenceType where S.Generator.Element ==
> Generator.Element>(elements:S) {
> self.init(isOrderedBefore: { $0 < $1 }, elements: elements)
> }
> }
>
>
> (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)
>
>
> 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.
>
> On 9 Mar 2016, at 08:30, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
> 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.
>
> Best,
> Austin
>
> On Mar 9, 2016, at 12:17 AM, David Hart <david at hartbit.com> wrote:
>
>
> On 08 Mar 2016, at 23:15, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I would prefer Equatable and Hashable to remain opt-in, and for us to add
> better support for automatic deriving of implementation.
>
>
> On 08 Mar 2016, at 23:57, Zach Waldowski via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
>
> 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:
>
> that would solve many of the common problems people currently have trying
> to work with heterogeneous containers.
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/95c2d82d/attachment.html>