> On 21 Nov 2017, at 07:31, Chris Lattner <clatt...@nondot.org> wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart <da...@hartbit.com >> <mailto:da...@hartbit.com>> wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto: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? > > Not above conditional and recursive conformances.
Correct. But recursive conformances are implemented and conditional conformances are on the way. To rephrase my question: doesn't this simplification of the type system hoist Variadic Generics to be the next big priority after conditional conformances are finished? >> • 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? > > I am not the expert on this (Doug Gregor is), but I think we can add it later > in an ABI additive way. > > -Chris > > > > > >>> 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 >>>> <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 <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
