Tuples cannot conform to protocols, so despite the existence of an “==”
operator for certain tuples, no tuple conforms to Equatable.
This is problematic, because it means that a function which takes a generic
Equatable parameter cannot be called with a tuple argument, even though an
applicable “==” operator exists.
(Ditto for “Comparable”, *mutatis mutandis*.)
On Sat, Oct 15, 2016 at 12:28 PM, Haravikk via swift-evolution <
> > On 15 Oct 2016, at 16:04, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> > Yes it absolutely matters what the types are. Two floating point values
> can compare equal when their raw bytes differ and they can compare not
> equal even when their raw bytes are the same, and it would be absolutely
> necessary that a tuple of two floating point values behaves the same way.
> > Moreover, if a value is not equatable, it's nonsense to ask if tuples of
> two of them are equal. Otherwise, you've effectively forced every value
> type to be equatable, since it'd be ridiculous if (a, a) == (b, b) didn't
> imply a == b.
> All I meant really is that you can always compare equality at the memory
> level, regardless of Equatable conformance; the type checker ensures the
> tuples being compared can only contain the same types in the same order, at
> which point a bitwise memory comparison can determine they are equal in the
> strictest possible sense, much like comparing whether two object references
> point to the same object (you're comparing the pointers).
> But actually it doesn't seem to even matter; tuples are already Equatable
> if all of their components are (again, something I don't seem to actually
> use), so that should be more than sufficient for using them as enum raw
> values, we can just ignore tuples that aren't/require the developer to add
> Equatable to any components that aren't.
> swift-evolution mailing list
swift-evolution mailing list