[swift-evolution] [Proposal] Change Void meaning

[John McCall]

> On Jun 12, 2017, at 6:42 PM, Vladimir.S <svabox at gmail.com> wrote:
> 
> 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.

It's not hard to figure out what any of these *should* do in Swift 4.  I'm not going to commit to promising that Swift 4 will not have bugs that cause deviations from that.  If the Core Team decides that something needs to happen with parameter destructuring in Swift 4, that will not go without comment here.

John.

> 
> 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