[swift-evolution] [Proposal] Change Void meaning

Tue Jun 13 06:23:23 CDT 2017

On 13.06.2017 3:35, John McCall wrote:
> 
>> 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.

Thank you for reply, but actually I was trying to figure out if I understand 
correctly "what any of these *should* do in Swift 4". Also, it will be great if we 
have a record of how such code at least *should* work in Swift 4, so we can refer to 
this.

So, again, I'm asking you or some one from core team to spent 1 minute to reply so we 
all have a clear view of expected results for this code. Thank you.

I do believe this is very important in lights of current debates regarding SE-0110 
changes(actually, I insist, more correct implementations of SE-0066) and probably can 
help to avoid the same problem after "bugs" will be fixed.

Btw, it is *very* strange for me that you are calling current behavior as "bugs", and 
even strange that these long-running "bugs" can be still with us in Swift 4 (note: 
SE-0066 and SE-0110 was accepted to be implemented in *Swift 3*).

And more important, as I understand, fixing these "bugs" will lead to *source 
breaking* changes, that is not possible for long time after Swift 4 release.
Plus, keeping these "bugs" leaves Swift in very broken state : we broke what was 
allowed in Swift 3 to fix the type system, but still have type system broken *in the 
same exact place*.

I really can't understand this. It is fundamentally that
type(of: fooParam) == type(of: fooTuple) even in Swift 4, it is not just a little 
"bug", code *will* use this "feature" and then we'll have a very loud voices about 
regressions in Swift if such "bug" will be "fixed". The same is for
fooParam is ((Int,Int))->()  and  fooTuple is (Int,Int)->()  and so on.
I can't see how this could be a bug fixing - it is fundamental changes in allowed 
syntax and in type system. And so this couldn't be done after Swift 4 release. No?

About this:
----
On 13.06.2017 2:24, Jens Persson wrote:
 > This: https://twitter.com/slava_pestov/status/874394132340289536
 > seems to suggest that the current Swift 4 behavior will not change much in this 
domain.
 >
----

It will be really *nice* to have a more detailed reply from core team regarding all 
this situation with SE-0025, SE-0066, SE-0110 implementations in Swift 4 and the 
"bugs" mentioned in my message, here in official swift evolution email list.

Vladimir.

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