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

[Austin Zheng]

I think we might (at least partially) be in violent agreement :). Most (if
not everyone) on this thread has agreed that painless opt-in
auto-conformance is a good thing ("struct Foo : Regular { .. }"), albeit
with differing definitions of 'painless'. But I maintain that having a
"func ==(lhs: Any, rhs: Any) -> Bool" stdlib fallback implementation of ==
is a lot of potential pain for very little benefit.

Austin

On Wed, Mar 9, 2016 at 1:17 PM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
> on Tue Mar 08 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:
>
> >> - Function types in Swift do not provide a ready equality
> > operation. We could provide a default implementation that always
> > returns 'false', perhaps.
> >
> > I think this sort of puts the lie to the idea.
> >
> > We can always provide *a* definition of equality, but I suspect it
> > will often be an *incorrect* definition.
>
> I disagree; IMO it would seldom be incorrect.
> But I wouldn't necessarily want to make everything equatable.  I'd want
> to give many things an equatable conformance that's available simply by
> declaring it. In fact, I'd like to be able to say:
>
>           struct Something : Regular {
>               // Stored properties that are all Regular
>           }
>
> and get Equatable, Comparable, and Hashable for free.


> > That's why you had to suggest functions should always be false: you
> > cannot (without more effort than you want to spend) provide a correct
> > definition of equality for it.
> >
> > I mean, imagine what happens if you make functions Equatable and
> > Hashable but with definitions that don't actually work. Currently,
> > `Set<Void -> Void>` gives you an error:
> >
> >       error: type 'Void -> Void' does not conform to protocol 'Hashable'
> >
> > But with this feature in place, Swift would happily produce a Set of
> > functions which collides endlessly, doesn't do any uniquing, never
> > says it contains any value you pass into it, and can only remove
> > elements by index.
> >
> > A type that is "never equal" completely breaks Set in practice, and
> > there's no way for the type system to catch the problem.
> >
> > If we automatically synthesize a == operator for every type, many of
> > those operators will be incorrect. For instance, anything that
> > includes a cache will be incorrect.
> > Anything that includes a pointer to a buffer and ought to evaluate the
> > buffer's contents will be incorrect.
> > Anything that includes a closure will be incorrect. Individually, each
> > of these cases is minor, but they multiply and interact with each
> > other until, together, they undermine confidence in ==.
>
> These things wouldn't be Regular by themselves.  To make them
> composable, you can create a single Regular value type that wraps each
> one.
>
> > If you explicitly mark things as Equatable, then it is clear that the
> > equality operator on them really does have a sensible definition. But
> > if you can pass anything into ==, you will never know what will
> > actually *work*. If everything's Equatable, then nothing is.
> >
> > * * *
> >
> > Auto-deriving is a different story, though, especially if it's opt-in
> > (you have to say `deriving Equatable`). There, you presumably have
> > looked at the default semantics and determined they're appropriate for
> > your type.
>
> I don't know if that level of explicitness is needed.  Explicit
> declaration of conformance might be enough.
>
> > But I think it's clear that derived conformances should eventually be
> > a user-accessible feature. We already derive RawRepresentable and
> > ErrorType on enums. (We also derive initializers on some types, but
> > that's arguably a separate feature.) I think it's clear that Swift ∞
> > ought to allow you to derive protocol conformances; it's just a matter
> > of scheduling.
> >
> > So I think that what we ought to do is this:
> >
> > • Make a best guess at what Swift ∞ would want you to do to invoke the
> > user-specified derivation logic for an arbitrary protocol—implicit
> > derivation or something marked by a keyword.
> > • Think about whether derived conformances of Equatable, Hashable,
> > and/or Comparable are urgent enough that we should implement them
> > before the general feature.
> > • If so, design these features along the lines of what we would expect
> > the eventual user-specified derivation feature to use.
>
> Of course.
>
> --
> -Dave
> _______________________________________________
> 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/0c96fc9c/attachment.html>