> On 21 Nov 2017, at 22:44, Douglas Gregor <dgre...@apple.com> wrote: > > > >>> On Nov 20, 2017, at 10:31 PM, Chris Lattner <clatt...@nondot.org> wrote: >>> >>> >>> >>> 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> 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. > > It’s in there under “extensions of structural types”, here: > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types > > with this example: > > extension<...Elements : Equatable> (Elements...) : Equatable { // > extending the tuple type "(Elements...)" to be Equatable > } > >>> Questions: >>> >>> • Doesn’t this simplification of the type system hoist Variadic Generics >>> back up the list of priorities? >> >> Not above conditional and recursive conformances. > > Right, and we don’t have bandwidth to take on Another Major Generics Feature > this year. > >> >>> • Would it be desirable to implement them before ABI stability to “remove” >>> tuples from the ABI? > > Tuples are structural types in the ABI (and type system), and should remain > that way. So, I disagree with Chris’s suggestion that (U, V, W) will become > Tuple<U, V, W>. The most relevant comparison today is Optional, which is > technically a nominal type but is treated as a special case basically > everywhere in the compiler (and ABI) because it should have been a structural > type. I expect optionals to become structural types in the future (the ABI is > designed for that) and tuples to remain structural types.
Can somebody explain to me what are nominal and structural types and why Optional should really be a structural type? >>> • 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. > > Yes, we can add it to the ABI later. > > - Doug > >> >> -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> 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
