[swift-evolution] Tuples as RawRepresentable

Nevin Brackett-Rozinsky nevin.brackettrozinsky at gmail.com
Sat Oct 15 12:21:15 CDT 2016

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 <
swift-evolution at swift.org> wrote:

> > On 15 Oct 2016, at 16:04, Xiaodi Wu <xiaodi.wu at 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 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/20161015/6a490a15/attachment.html>

More information about the swift-evolution mailing list