<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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.<div><br></div><div>Austin</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Mar 9, 2016 at 1:17 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
on Tue Mar 08 2016, Brent Royal-Gordon <brent-AT-architechies.com> wrote:<br>
<br>
>> - Function types in Swift do not provide a ready equality<br>
> operation. We could provide a default implementation that always<br>
> returns 'false', perhaps.<br>
><br>
> I think this sort of puts the lie to the idea.<br>
><br>
> We can always provide *a* definition of equality, but I suspect it<br>
> will often be an *incorrect* definition.<br>
<br>
</span>I disagree; IMO it would seldom be incorrect.<br>
But I wouldn't necessarily want to make everything equatable. I'd want<br>
to give many things an equatable conformance that's available simply by<br>
declaring it. In fact, I'd like to be able to say:<br>
<br>
struct Something : Regular {<br>
// Stored properties that are all Regular<br>
}<br>
<br>
and get Equatable, Comparable, and Hashable for free.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> That's why you had to suggest functions should always be false: you<br>
> cannot (without more effort than you want to spend) provide a correct<br>
> definition of equality for it.<br>
><br>
> I mean, imagine what happens if you make functions Equatable and<br>
> Hashable but with definitions that don't actually work. Currently,<br>
> `Set<Void -> Void>` gives you an error:<br>
><br>
> error: type 'Void -> Void' does not conform to protocol 'Hashable'<br>
><br>
> But with this feature in place, Swift would happily produce a Set of<br>
> functions which collides endlessly, doesn't do any uniquing, never<br>
> says it contains any value you pass into it, and can only remove<br>
> elements by index.<br>
><br>
> A type that is "never equal" completely breaks Set in practice, and<br>
> there's no way for the type system to catch the problem.<br>
><br>
> If we automatically synthesize a == operator for every type, many of<br>
> those operators will be incorrect. For instance, anything that<br>
> includes a cache will be incorrect.<br>
> Anything that includes a pointer to a buffer and ought to evaluate the<br>
> buffer's contents will be incorrect.<br>
> Anything that includes a closure will be incorrect. Individually, each<br>
> of these cases is minor, but they multiply and interact with each<br>
> other until, together, they undermine confidence in ==.<br>
<br>
</span>These things wouldn't be Regular by themselves. To make them<br>
composable, you can create a single Regular value type that wraps each<br>
one.<br>
<span class=""><br>
> If you explicitly mark things as Equatable, then it is clear that the<br>
> equality operator on them really does have a sensible definition. But<br>
> if you can pass anything into ==, you will never know what will<br>
> actually *work*. If everything's Equatable, then nothing is.<br>
><br>
> * * *<br>
><br>
> Auto-deriving is a different story, though, especially if it's opt-in<br>
> (you have to say `deriving Equatable`). There, you presumably have<br>
> looked at the default semantics and determined they're appropriate for<br>
> your type.<br>
<br>
</span>I don't know if that level of explicitness is needed. Explicit<br>
declaration of conformance might be enough.<br>
<span class=""><br>
> But I think it's clear that derived conformances should eventually be<br>
> a user-accessible feature. We already derive RawRepresentable and<br>
> ErrorType on enums. (We also derive initializers on some types, but<br>
> that's arguably a separate feature.) I think it's clear that Swift ∞<br>
> ought to allow you to derive protocol conformances; it's just a matter<br>
> of scheduling.<br>
><br>
> So I think that what we ought to do is this:<br>
><br>
> • Make a best guess at what Swift ∞ would want you to do to invoke the<br>
> user-specified derivation logic for an arbitrary protocol—implicit<br>
> derivation or something marked by a keyword.<br>
> • Think about whether derived conformances of Equatable, Hashable,<br>
> and/or Comparable are urgent enough that we should implement them<br>
> before the general feature.<br>
> • If so, design these features along the lines of what we would expect<br>
> the eventual user-specified derivation feature to use.<br>
<br>
</span>Of course.<br>
<span class=""><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>