[swift-evolution] Tuples as Named Types

[Robert Widmann]

A few notes

~Robert Widmann

2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160916/3d13100e/attachment.html>