A few notes

~Robert Widmann

2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution 
<[email protected]> のメッセージ:

> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to