Forwarding this reply to the list because I hit the wrong button.
> Begin forwarded message:
>
> From: Robert Widmann <devteam.cod...@gmail.com>
> Subject: Re: [swift-evolution] [Proposal] Tuple Extensions
> Date: May 4, 2016 at 4:45:21 PM EDT
> To: Joe Groff <jgr...@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 <jgr...@apple.com> wrote:
>>
>>
>>> On May 3, 2016, at 10:06 PM, Robert Widmann <devteam.cod...@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 <jgr...@apple.com> のメッセージ:
>>>
>>>>
>>>>> On May 3, 2016, at 9:52 PM, Robert Widmann <devteam.cod...@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
>>
> 
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
