> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Yes, I agree, we need variadic generics before we can have tuples conform :-(
Well, we don’t *have* to have variadic generics to allow structural types to
conform… it just composes really, really elegantly. One could certainly allow
extensions of tuple types with fixed arity, which would then provide
conditional conformances:
extension<T: Equatable, U: Equatable> (T, U): Equatable {
// ...
}
extension<T: Equatable, U: Equatable, V: Equatable> (T, U, V): Equatable {
// ...
}
Yes, the variadic suggestion is more general and more elegant, but these are
orthogonal features.
> 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.
As noted in my previous reply, we don’t need Tuple<U, V, W> to make this work.
> 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.
Variadics aren’t enough to fully generalize parameter lists, though, because
they don’t capture calling conventions. It’s actually a bit of an issue for
Swift, because something variadic like:
extension<Result, …Params…> (Params…) -> Result { }
Isn’t going to work with “inout”, or with shared/owned (whatever is not the
default).
- Doug
>
> -Chris
>
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov <spes...@apple.com
>> <mailto:spes...@apple.com>> 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
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
>>> <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
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <kelvin1...@gmail.com
>>> <mailto:kelvin1...@gmail.com>> 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 <clatt...@nondot.org
>>>> <mailto:clatt...@nondot.org>> wrote:
>>>>
>>>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> when SE-185
>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>>>>> went through swift evolution, it was agreed that the next logical step
>>>>> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> 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
>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>>>>> 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
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
