[swift-evolution] Tuples as RawRepresentable

[Xiaodi Wu]

It may be farther reaching, but it's quite salient. Completing genetics is
a Swift 4 focus, and protocol conformance and extensions of structural
types may well have ABI implications, which would make it a phase 1
priority.

Recall that equality for tuples of Equatables is only defined up to an
arity of 6, and that it was implemented in that way as a stopgap. With a
plausible definitive solution in scope for Swift 4, it seems less than
ideal to propose entrenching the stopgap measure by making it even more
elaborate.

On Sun, Oct 16, 2016 at 19:47 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 16 Oct 2016, at 11:55, Karl <razielim at gmail.com> wrote:
>
>
> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky <
> nevin.brackettrozinsky at gmail.com> wrote:
>
> 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*.)
>
> Nevin
>
>
> Yeah, since the operators are implemented though perhaps some kind of
> magic can be used? It seems strange that the following is valid:
>
> struct Foo : Equatable { let value:(Int, Int) }
> func == (lhs:Foo, rhs:Foo) -> Bool { return lhs.value == rhs.value }
>
> Yet tuples can't just be Equatable etc. But I'm wondering whether that
> falls into separate issue territory, such that it should be done first as
> its own proposal?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Tuples are non-nominal (named) types, and that’s why they can’t conform to
> protocols. There is something in the generics manifesto about possibly
> allowing them to do that in the future, though:
>
>
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>
> Extensions of structural types
>
> Currently, only nominal types (classes, structs, enums, protocols) can be
> extended. One could imagine extending structural types—particularly tuple
> types—to allow them to, e.g., conform to protocols. For example, pulling
> together variadic generics, parameterized extensions, and conditional
> conformances, one could express "a tuple type is Equatable if all of its
> element types are Equatable":
>
> extension<...Elements : Equatable> (Elements...) : Equatable {   // extending the tuple type "(Elements...)" to be Equatable
> }
>
> - Karl
>
>
> Yeah, but that's much further reaching overall; I'm wondering whether it's
> okay to just call tuples of Equatable types Equatable for the purposes of
> getting them as enum raw values? I'll maybe put some discussion of timing
> and other issues into the proposal for this, to keep it open ended.
> _______________________________________________
> 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/20161016/3b0b6c0f/attachment.html>