If we wish to think more generally, would it then be necessary to, say, implement a finitary version of tuple extensions as an overload of the infinitary one?
> On May 4, 2016, at 4:50 PM, Matthew Johnson <[email protected]> wrote: > >> >> On May 4, 2016, at 3:46 PM, Robert Widmann via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Forwarding this reply to the list because I hit the wrong button. >> >>> Begin forwarded message: >>> >>> From: Robert Widmann <[email protected] >>> <mailto:[email protected]>> >>> Subject: Re: [swift-evolution] [Proposal] Tuple Extensions >>> Date: May 4, 2016 at 4:45:21 PM EDT >>> To: Joe Groff <[email protected] <mailto:[email protected]>> >>> >>> Isn’t this assuming that tuples extensions would only come in one flavor? >>> There will always be cases where you need to limit an extension to a finite >>> arity (for me, Swiftz needs a proper Bifunctor instance for tuples), >>> something that a variadic tuple extension could not support (at least, not >>> according anything I’ve read proposed). When the time comes to support the >>> infinitary version of these extensions, it’s not that the runtime will >>> carry around the crud left over from the old hat finite version, it’s that >>> the runtime will support both finitary and infinitary tuple extensions. > > If the standard library implemented finite-arity versions of theoretically > variadic functions such as == those would need to remain in the library in > order to remain ABI compliant. > >>> >>>> On May 4, 2016, at 11:47 AM, Joe Groff <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On May 3, 2016, at 10:06 PM, Robert Widmann <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Once-and-for-all implementations come in many flavors. For now, we have >>>>> clear interest in making a limited subset of possible tuples properly >>>>> Comparable. This will also make it easier to implement extensions to >>>>> specific arities now and serve as a base for variadic generics if that is >>>>> the path we take. I could certainly see Future Swift™ allowing this to >>>>> sit side-by-side with the finite version in this proposal, couldn't you? >>>>> >>>>> extension (T...) : Equatable where T.Element : Equatable { } >>>>> >>>>> func == <T : Equatable>(l : (T...), r : (T...)) -> Bool { /* .. */ } >>>> >>>> One problem with introducing variadics later would be that, if we ship the >>>> specific-arity conformances in an ABI-stable standard library, we're stuck >>>> carrying those extensions around forever for backward compatibility. >>>> >>>> -Joe >>>> >>>>> ~Robert Widmann >>>>> >>>>> 2016/05/04 0:54、Joe Groff <[email protected] <mailto:[email protected]>> >>>>> のメッセージ: >>>>> >>>>>> >>>>>>> On May 3, 2016, at 9:52 PM, Robert Widmann <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Trouble is that I don't want variadic generics without corresponding >>>>>>> support from the type system which is untenable without HKTs (see last >>>>>>> paragraph of proposal). C++'s variadic implementation of std::tuple is >>>>>>> not elegant to my mind, and would have no place in a library I could >>>>>>> think of writing. >>>>>> >>>>>> I think we'd keep tuples as a builtin type. Variadics would just let you >>>>>> implement Equatable/Hashable/etc. once for all tuple arities. I don't >>>>>> see why we'd need HKTs for that. >>>>>> >>>>>> -Joe >>>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
