> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution > <swift-evolution@swift.org> 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).
Eye-opening! Now I understand how important variadic generics are. Somebody should add that example to the Generics Manifesto. Questions: • Doesn’t this simplification of the type system hoist Variadic Generics back up the list of priorities? • Would it be desirable to implement them before ABI stability to “remove” tuples from the ABI? • If not, is the current ABI already flexible enough to support them if they are implemented later on? > 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 <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> 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 >>>> <swift-evolution@swift.org> wrote: >>>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma <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> >>>>>> wrote: >>>>>> >>>>>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution >>>>>>> <swift-evolution@swift.org> 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 >>>> 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 >> > > _______________________________________________ > 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
