John, could you clarify the details regarding function types, SE-0066 and SE-0110 implementations *planned* for Swift 4 release? I believe all these are important questions to be answered to understand the near feature of Swift and to be prepared for changes.
Given :
func fooParam(_ x: Int, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}
and
var closureParam = { (x: Int, y: Int) in print("in closureParam") }
var closureTuple = { (x: (Int, Int)) in }
* What will be the result in Swift 4 release? :
   1. type(of:fooParam)
   2. type(of:fooTuple)
   3. type(of:closureParam)
   4. type(of:closureTuple)
* Will this be true in Swift 4 release? :
   1. type(of: fooParam) == type(of: fooTuple)
   2. fooParam is ((Int,Int))->()
   3. fooTuple is (Int,Int)->()
   4. type(of: closureParam) == type(of: closureTuple)
   5. closureParam is ((Int,Int))->()
   6. closureTuple is (Int,Int)->()
* Will this code still be valid in Swift 4 release? :
   1.
  closureTuple = closureParam
  closureTuple((1,2)) // prints "in closureParam"
   2.
  var f: () -> Int = { 5 } // function with no parameters
  var g: (()) -> Int = { 5 } // function taking a single () parameter
  f = g
  f()
* Does core team plan to introduce some syntactic sugar for tuple argument destructuring in closures *before* Swift 4 release?
If so, what do you think about a suggestion to allow type inference for currently allowed syntax for tuple argument destructuring? I.e.
allowed: .filter {(friend: (name: String, age: Int)) in friend.age >= 18 }
proposed: .filter {(friend: (name, age)) in friend.age >= 18 }
* And the same for passing function with no parameters if function with single Void parameter is expected? I.e. in such situation:
func foo<T>(_ callback: (T)->Void) {}
func bar(){}
foo(bar)
Thank you for your time.
Vladimir.
···
On 12.06.2017 20:15, John McCall via swift-evolution wrote:
On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi here,
As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples usage.
After documenting myself about the changes which happened, I thought that they could be improved. Instead of fighting these propositions (which make sense), I wanted create a few proposal which would improve these recent changes with a few simple rules.
My propositions are based on the recent decisions and in the continuation of SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. The reason of this is that arguments were initially considered as tuple.
The dominant consideration here was always return types, not parameters. I'm not sure there was ever much point in writing Void in a parameter list, but whatever reasons there were surely vanished with SE-0066.
Note that 'void' in C was originally exclusively a return type. ANSI gave it a new purpose it with void*, but the meaning is totally unrelated.
John.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
