[swift-evolution] [Proposal] Tuple Extensions

[Robert Widmann]

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 <matthew at anandabits.com> wrote:
> 
>> 
>> On May 4, 2016, at 3:46 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Forwarding this reply to the list because I hit the wrong button.
>> 
>>> Begin forwarded message:
>>> 
>>> From: Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>>
>>> Subject: Re: [swift-evolution] [Proposal] Tuple Extensions
>>> Date: May 4, 2016 at 4:45:21 PM EDT
>>> To: Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>>
>>> 
>>> 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 <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On May 3, 2016, at 10:06 PM, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> 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 <jgroff at apple.com <mailto:jgroff at apple.com>> のメッセージ:
>>>>> 
>>>>>> 
>>>>>>> On May 3, 2016, at 9:52 PM, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160504/6b7fad01/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160504/6b7fad01/attachment.sig>