Forwarding this reply to the list because I hit the wrong button.
···
Begin forwarded message:
From: Robert Widmann <devteam.codafi@gmail.com>
Subject: Re: [swift-evolution] [Proposal] Tuple Extensions
Date: May 4, 2016 at 4:45:21 PM EDT
To: Joe Groff <jgroff@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@apple.com> wrote:
On May 3, 2016, at 10:06 PM, Robert Widmann <devteam.codafi@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 { }
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.
On May 3, 2016, at 9:52 PM, Robert Widmann <devteam.codafi@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.
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@anandabits.com> wrote:
On May 4, 2016, at 3:46 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Forwarding this reply to the list because I hit the wrong button.
Begin forwarded message:
From: Robert Widmann <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>>
Subject: Re: [swift-evolution] [Proposal] Tuple Extensions
Date: May 4, 2016 at 4:45:21 PM EDT
To: Joe Groff <jgroff@apple.com <mailto:jgroff@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@apple.com <mailto:jgroff@apple.com>> wrote:
On May 3, 2016, at 10:06 PM, Robert Widmann <devteam.codafi@gmail.com <mailto:devteam.codafi@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 { }
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.
On May 3, 2016, at 9:52 PM, Robert Widmann <devteam.codafi@gmail.com <mailto:devteam.codafi@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.