[swift-evolution] [Proposal] Tuple Extensions

[Robert Widmann]

Forwarding this reply to the list because I hit the wrong button.

> Begin forwarded message:
> 
> From: Robert Widmann <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>
> 
> 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.
> 
>> On May 4, 2016, at 11:47 AM, Joe Groff <jgroff at apple.com> wrote:
>> 
>> 
>>> On May 3, 2016, at 10:06 PM, Robert Widmann <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> のメッセージ:
>>> 
>>>> 
>>>>> On May 3, 2016, at 9:52 PM, Robert Widmann <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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160504/8af04f73/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/8af04f73/attachment.sig>