[Proposal] Tuple Extensions


(Robert Widmann) #1

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they have some kind of special status in the language. Yet, tuples are an opaque concept exposed by the compiler to the end user with no opportunity for extension. Languages that have tried to expose tuples to their users for extension have done so in less than ideal ways (see Tuple1-Tuple22 Scala <https://github.com/scala/scala/blob/2.12.x/src/library/scala/Tuple22.scala>, Haskell <https://github.com/ghc/ghc/blob/master/libraries/ghc-prim/GHC/Tuple.hs>’s hard limit on tuples, Rust <https://doc.rust-lang.org/std/primitive.tuple.html>’s limitations for std::tuple), yet each implementation has something to offer a possible Swift implementation. I see only one course of action that will bring us extensible tuples in a manner that is compatible with Swift and its overall design philosophy. To that end, I have drawn up a draft proposal <https://gist.github.com/CodaFi/18b70633b03e19161402ae3579c072b7> for generic tuple extensions that I will submit to swift-evolution shortly.

All the best,

~Robert Widmann


(Joe Groff) #2

Tuples are a special case of a more general shortcoming, which is that you can't extend *any* of the builtin structural types, not only tuples but metatypes, function types, and existentials. I don't see any reason to address this for tuples only. In the particular case of tuples, I think you really want variadic generic parameters too, to be able to extend them to arbitrary arities without having to waste space generating boilerplate for a bunch of fixed arities. Both structural type extensions and variadic generics are covered in Doug's omnibus generics roadmap: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html

-Joe

···

On May 3, 2016, at 9:13 PM, Developer via swift-evolution <swift-evolution@swift.org> wrote:

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they have some kind of special status in the language. Yet, tuples are an opaque concept exposed by the compiler to the end user with no opportunity for extension. Languages that have tried to expose tuples to their users for extension have done so in less than ideal ways (see Tuple1-Tuple22 Scala, Haskell’s hard limit on tuples, Rust’s limitations for std::tuple), yet each implementation has something to offer a possible Swift implementation. I see only one course of action that will bring us extensible tuples in a manner that is compatible with Swift and its overall design philosophy. To that end, I have drawn up a draft proposal for generic tuple extensions that I will submit to swift-evolution shortly.


(Austin Zheng) #3

+1 to the interaction between variadic generics and extension of tuple
types. But this is a proposal I hope to see accepted and implemented at
some point.

Is there an official formatted version of the manifesto? I put together a
gist with markdown formatting but would much rather direct people to an
official copy if one exists. (
https://gist.github.com/austinzheng/7cd427dd1a87efb1d94481015e5b3828)

Austin

···

On Tue, May 3, 2016 at 9:47 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:

> On May 3, 2016, at 9:13 PM, Developer via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I’ve been contemplating this idea for a while now, mostly because I
think it’s a very important feature, but also because I can’t find a single
example of a programming language getting it completely right. In Swift,
the motif of tuples throughout the language would lead one to think that
they have some kind of special status in the language. Yet, tuples are an
opaque concept exposed by the compiler to the end user with no opportunity
for extension. Languages that have tried to expose tuples to their users
for extension have done so in less than ideal ways (see Tuple1-Tuple22
Scala, Haskell’s hard limit on tuples, Rust’s limitations for std::tuple),
yet each implementation has something to offer a possible Swift
implementation. I see only one course of action that will bring us
extensible tuples in a manner that is compatible with Swift and its overall
design philosophy. To that end, I have drawn up a draft proposal for
generic tuple extensions that I will submit to swift-evolution shortly.

Tuples are a special case of a more general shortcoming, which is that you
can't extend *any* of the builtin structural types, not only tuples but
metatypes, function types, and existentials. I don't see any reason to
address this for tuples only. In the particular case of tuples, I think you
really want variadic generic parameters too, to be able to extend them to
arbitrary arities without having to waste space generating boilerplate for
a bunch of fixed arities. Both structural type extensions and variadic
generics are covered in Doug's omnibus generics roadmap:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

It would be great for someone to convert it into a markdown file in swift/docs.

-Chris

···

On May 3, 2016, at 9:50 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

+1 to the interaction between variadic generics and extension of tuple types. But this is a proposal I hope to see accepted and implemented at some point.

Is there an official formatted version of the manifesto? I put together a gist with markdown formatting but would much rather direct people to an official copy if one exists. (https://gist.github.com/austinzheng/7cd427dd1a87efb1d94481015e5b3828)


(Robert Widmann) #5

The proposal draft on Github <https://github.com/apple/swift-evolution/pull/290> is now live.

···

On May 4, 2016, at 12:13 AM, Developer <devteam.codafi@gmail.com> wrote:

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they have some kind of special status in the language. Yet, tuples are an opaque concept exposed by the compiler to the end user with no opportunity for extension. Languages that have tried to expose tuples to their users for extension have done so in less than ideal ways (see Tuple1-Tuple22 Scala <https://github.com/scala/scala/blob/2.12.x/src/library/scala/Tuple22.scala>, Haskell <https://github.com/ghc/ghc/blob/master/libraries/ghc-prim/GHC/Tuple.hs>’s hard limit on tuples, Rust <https://doc.rust-lang.org/std/primitive.tuple.html>’s limitations for std::tuple), yet each implementation has something to offer a possible Swift implementation. I see only one course of action that will bring us extensible tuples in a manner that is compatible with Swift and its overall design philosophy. To that end, I have drawn up a draft proposal <https://gist.github.com/CodaFi/18b70633b03e19161402ae3579c072b7> for generic tuple extensions that I will submit to swift-evolution shortly.

All the best,

~Robert Widmann


(Robert Widmann) #6

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.

~Robert Widmann

2016/05/04 0:47、Joe Groff <jgroff@apple.com> のメッセージ:

···

On May 3, 2016, at 9:13 PM, Developer via swift-evolution <swift-evolution@swift.org> wrote:

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they have some kind of special status in the language. Yet, tuples are an opaque concept exposed by the compiler to the end user with no opportunity for extension. Languages that have tried to expose tuples to their users for extension have done so in less than ideal ways (see Tuple1-Tuple22 Scala, Haskell’s hard limit on tuples, Rust’s limitations for std::tuple), yet each implementation has something to offer a possible Swift implementation. I see only one course of action that will bring us extensible tuples in a manner that is compatible with Swift and its overall design philosophy. To that end, I have drawn up a draft proposal for generic tuple extensions that I will submit to swift-evolution shortly.

Tuples are a special case of a more general shortcoming, which is that you can't extend *any* of the builtin structural types, not only tuples but metatypes, function types, and existentials. I don't see any reason to address this for tuples only. In the particular case of tuples, I think you really want variadic generic parameters too, to be able to extend them to arbitrary arities without having to waste space generating boilerplate for a bunch of fixed arities. Both structural type extensions and variadic generics are covered in Doug's omnibus generics roadmap: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html

-Joe


(Joe Groff) #7

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

···

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.


(Robert Widmann) #8

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 { /* .. */ }

~Robert Widmann

2016/05/04 0:54、Joe Groff <jgroff@apple.com> のメッセージ:

···

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.

-Joe


(Joe Groff) #9

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

···

On May 3, 2016, at 10:06 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:

~Robert Widmann

2016/05/04 0:54、Joe Groff <jgroff@apple.com> のメッセージ:

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.

-Joe