In Scala they just define Tuple1<A>, Tuple2<A, B>, ... up to 22 (I think).
Eliminates the need for variadic generics and works fine in practice in Scala.
In Swift this approach is possibly unacceptable, since having to write:
extension Tuple1 ...
extension Tuple2 ...
...
extension Tuple22 ...
Is a real pain.
However if we added variadic generics, Tuple<T...>, then we would also need a
tuple to become a Collection (or some minimal subset of), e.g.:
extension Tuple: Equatable where T: Equatable {
static func == (lhs: Tuple, rhs: Tuple) -> Bool {
guard lhs.count == rhs.count else {
return false
}
for i in 0 ..< lhs.count {
guard lhs[i] == rhs[i] else {
return false
}
}
return true
}
}
Note how the tuple is treated like a collection. The compiler magic would be to
make a Tuple a collection, which is more ‘magic’ than ‘magically’ adding
Hashable :).
Despite the profusion of magic, variadic generics and Tuple collection
additions are my favourite option.
-- Howard.
> On 21 Nov 2017, at 1:17 pm, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> Yes, I agree, we need variadic generics before we can have tuples conform :-(
>
> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for
> Tuple<U,V,W> just like we handle array sugar. When that is possible, Tuple
> is just a type like any other in the system (but we need variadics to express
> it).
>
> Once you have that, then you could write conformances in general, as well as
> conditional conformances that depend on (e.g.) all the element types being
> equatable.
>
>
> We also need that to allow functions conform to protocols, because functions
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of
> the function type, and the parameter list needs variadics.
>
> -Chris
>
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov <[email protected]> wrote:
>>
>> Ignoring synthesized conformances for a second, think about how you would
>> manually implement a conformance of a tuple type to a protocol. You would
>> need some way to statically “iterate” over all the component types of the
>> tuple — in fact this is the same as having variadic generics.
>>
>> If we had variadic generics, we could implement tuples conforming to
>> protocols, either by refactoring the compiler to allow conforming types to
>> be non-nominal, or by reworking things so that a tuple is a nominal type
>> with a single variadic generic parameter.
>>
>> Slava
>>
>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> This is something I've wanted to look at for a while. A few weeks ago I
>>> pushed out https://github.com/apple/swift/pull/12598 to extend the existing
>>> synthesis to handle structs/enums when a field/payload has a tuple of
>>> things that are Equatable/Hashable, and in that PR it was (rightly)
>>> observed, as Chris just did, that making tuples conform to protocols would
>>> be a more general solution that solves the same problem you want to solve
>>> here.
>>>
>>> I'd love to dig into this more, but last time I experimented with it I got
>>> stuck on places where the protocol conformance machinery expects
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that
>>> logic up to was (since tuples don't have a corresponding Decl from what I
>>> can tell). Any pointers?
>>>
>>>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution
>>>> <[email protected]> wrote:
>>>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <[email protected]> wrote:
>>>>> the end goal here is to use tuples as a compatible currency type, to that
>>>>> end it makes sense for these three protocols to be handled as “compiler
>>>>> magic” and to disallow users from manually defining tuple conformances
>>>>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
>>>>> Comparable are special because they’re the basis for a lot of standard
>>>>> library functionality so i think the benefits of making this a special
>>>>> supported case outweigh the additional language opacity.
>>>>
>>>> I understand your goal, but that compiler magic can’t exist until there is
>>>> something to hook it into. Tuples can’t conform to protocols right now,
>>>> so there is nothing that can be synthesized.
>>>>
>>>> -Chris
>>>>
>>>>
>>>>>
>>>>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>> when SE-185 went through swift evolution, it was agreed that the next
>>>>>>> logical step is synthesizing these conformances for tuple types, though
>>>>>>> it was left out of the original proposal to avoid mission creep. I
>>>>>>> think now is the time to start thinking about this. i’m also tacking on
>>>>>>> Comparable to the other two protocols because there is precedent in the
>>>>>>> language from SE-15 that tuple comparison is something that makes sense
>>>>>>> to write.
>>>>>>>
>>>>>>> EHC conformance is even more important for tuples than it is for
>>>>>>> structs because tuples effectively have no workaround whereas in
>>>>>>> structs, you could just manually implement the conformance.
>>>>>>
>>>>>> In my opinion, you’re approaching this from the wrong direction. The
>>>>>> fundamental problem here is that tuples can’t conform to a protocol. If
>>>>>> they could, synthesizing these conformances would be straight-forward.
>>>>>>
>>>>>> If you’re interested in pushing this forward, the discussion is “how do
>>>>>> non-nominal types like tuples and functions conform to protocols”?
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
