So (borrowing C++-ish notation), a function of type `(Args...) -> Result` would become sugar for something like `Function<Args..., Result>`? That certainly makes sense.
How would throw-ness be handled—would we need ThrowingFunction and Function, with the ability to coerce Function -> ThrowingFunction? (Async might pose similar issues?) On Mon, Nov 20, 2017 at 6:17 PM Chris Lattner <clatt...@nondot.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). > > 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 >>> <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 >> 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
