[swift-evolution] [Proposal] Change Void meaning

[Vladimir.S]

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 at swift.org <mailto:swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>