> On Nov 20, 2017, at 10:24 PM, David Hart <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. > • 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
