Tuples as Named Types

Evolution Discussion
1

The purpose of this proposal is to implement Tuples as a named typed in
Swift. Tuples can be extremely useful for pattern matching, returning
multiple values from a function, and destructing content to the list. C#
has tuples as a named type as well I believe. Currently, Tuples in Swift
are anonymous types that have limited functionality but this proposal can
help solve that.

The underlying implementations of this proposal can allow the following :

1) having parameters and return values of type : Tuple
- enforces much more intuitive and clean code
- less code too read

2) implicit & explicit optionals with tuples !!!
- Can definitely take out many nested optional chains if tuples internally
checks for .Some or .None in each variable stored inside of an optional of
type Tuple.

3) making tuples variable declarations more popular for functional call
- parameter names in function calls within tuple variables can be used as
getter

My proposal was very brief but I hope its one worth embracing. I didnt get
to talk about applications but those are pretty self-explanatory. This
definitely widens the vision for Swift and could be a "a-ha" thing for
Swift developers. :)

···

--
Best Regards,

Muhammad T. Vali

2

A few notes

~Robert Widmann

2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution <swift-evolution@swift.org> のメッセージ:

The purpose of this proposal is to implement Tuples as a named typed in Swift. Tuples can be extremely useful for pattern matching, returning multiple values from a function, and destructing content to the list. C# has tuples as a named type as well I believe. Currently, Tuples in Swift are anonymous types that have limited functionality but this proposal can help solve that.

Languages like C#, Scala, et al. that decided that Tuple should be a nominal type have, in my opinion, made the wrong choice. A tuple is an anonymous product; its content and not its name is what is important otherwise you'd just use a struct.

The underlying implementations of this proposal can allow the following :

1) having parameters and return values of type : Tuple
- enforces much more intuitive and clean code
- less code too read

This is already valid in Swift.

func flip<A, B>(_ t : (A, B)) -> (B, A) {
  return (t.1, t.0)
}

2) implicit & explicit optionals with tuples !!!
- Can definitely take out many nested optional chains if tuples internally checks for .Some or .None in each variable stored inside of an optional of type Tuple.

This operation will not scale well without variadic generics. Do you really want ~8 different functions in stdlib that examine the contents of tuples when it's much easier to just pattern match on the tuple in a `switch` or `case let` statement?

3) making tuples variable declarations more popular for functional call
- parameter names in function calls within tuple variables can be used as getter

This is, again, already supported.

func project(_ t : (l : String, r : Int)) -> Int {
  return t.r
}

f(("Hello World, 42))

My proposal was very brief but I hope its one worth embracing. I didnt get to talk about applications but those are pretty self-explanatory. This definitely widens the vision for Swift and could be a "a-ha" thing for Swift developers. :)

In short, I don't really see how this achieves the goal of making tuples more flexible. Perhaps you have concrete examples of what is wrong and what this proposal intends to fix?

···

--
Best Regards,

Muhammad T. Vali
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

~Robert Widmann

2016/09/16 10:03、Muhammad Tahir Vali <tahir.vali13@gmail.com> のメッセージ:

Type safety would make tuples far more powerful than their current limitations.

Tuples, like every other language construct in Swift are typed. If you find a situation where they aren't, please let us know via JIRA or radar.

Structs are usually used for slightly more complex objects compared to tuples and usually, you need them longer in memory.

How is this a limitation?

Tuples are just for quick manipulation. Since you are interested in just the content inside, you should be able to manipulate it quickly. Concrete examples would be destructing JSON or manipulating any list. That manipulation itself shouldn't be something used with Switch statements or require multiple if let statements.

A tuple is just as valid a data structure as any. Though you may use them less, it does not mean they exist in a different semantic space than nominal types. I don't see why you are averse to switch and case-let. Switch allows you all the same power as your suggestion of using functions to "squash out" the Optionals from a tuple, and gives you diagnostics about completeness of case handling to boot.

To your point, both of the operations you describe above are handled by destructuring into enums with associated values, not by matching on tuple patterns. In fact, I think the only convincing case I've seen for the absolute need for tuple patterns is HLists , and nobody uses those anyway ;)

I'm actually not a fan of the C#'s implementation of tuples. Mainly because they don't use optionals and the tuple implementation isn't very clean

var aTuple = Tuple.Create ("foo","bar",111)

The main problem is that Swift's tuples functionalities are very limited to be able to use them.

This is what I would like you to explain. Please expound on the current limitations and what you wish to change. So far, all I've seen is a suggestion for Monoidal Functors in stdlib.

···

On Thu, Sep 15, 2016 at 10:25 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
A few notes

~Robert Widmann

2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution <swift-evolution@swift.org> のメッセージ:

The purpose of this proposal is to implement Tuples as a named typed in Swift. Tuples can be extremely useful for pattern matching, returning multiple values from a function, and destructing content to the list. C# has tuples as a named type as well I believe. Currently, Tuples in Swift are anonymous types that have limited functionality but this proposal can help solve that.

Languages like C#, Scala, et al. that decided that Tuple should be a nominal type have, in my opinion, made the wrong choice. A tuple is an anonymous product; its content and not its name is what is important otherwise you'd just use a struct.

The underlying implementations of this proposal can allow the following :

1) having parameters and return values of type : Tuple
- enforces much more intuitive and clean code
- less code too read

This is already valid in Swift.

func flip<A, B>(_ t : (A, B)) -> (B, A) {
  return (t.1, t.0)
}

2) implicit & explicit optionals with tuples !!!
- Can definitely take out many nested optional chains if tuples internally checks for .Some or .None in each variable stored inside of an optional of type Tuple.

This operation will not scale well without variadic generics. Do you really want ~8 different functions in stdlib that examine the contents of tuples when it's much easier to just pattern match on the tuple in a `switch` or `case let` statement?

3) making tuples variable declarations more popular for functional call
- parameter names in function calls within tuple variables can be used as getter

This is, again, already supported.

func project(_ t : (l : String, r : Int)) -> Int {
  return t.r
}

f(("Hello World, 42))

My proposal was very brief but I hope its one worth embracing. I didnt get to talk about applications but those are pretty self-explanatory. This definitely widens the vision for Swift and could be a "a-ha" thing for Swift developers. :)

In short, I don't really see how this achieves the goal of making tuples more flexible. Perhaps you have concrete examples of what is wrong and what this proposal intends to fix?

--
Best Regards,

Muhammad T. Vali
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Best Regards,

Muhammad T. Vali