[swift-evolution] Revisiting SE-0110

[Vladimir.S]

On 06.06.2017 20:10, Mark Lacey via swift-evolution wrote:
> 
>> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution <swift-evolution at swift.org 
>> <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>> FWIW, after doing a project migration last night and this morning, I am reluctantly 
>> +1 for reverting SE-0110 and seeing a new proposal that can be properly evaluated. 
>>  The split-the-difference compromise mentioned seems like just that, a compromise 
>> that will need to be revisited anyway.
>>
>> While I agreed with the spirit of the original proposal, the assertion that "Minor 
>> changes to user code may be required if this proposal is accepted.” seems like it 
>> underestimated the magnitude of the impact. In almost every case, my code lost clarity.
> 
> Did you run into issues other than the “tuple destructuring” issue that began this 
> thread?
> 
> If so, can you provide some examples to illustrate what other issues people are 
> hitting in practice?
> 
> I put “tuple destructuring” in quotes here because although it looks very much like 
> what is happening in Swift 3 and earlier, there was no real tuple destructuring 
> support in parameters (as evidenced by the fact that things like (x, (y, z)) never 
> worked).
> 
> The behavior of allowing:
>    [“key” : 1].map { key, value in … }
> is the result of allowing the two-argument closure to be passed to a function (map) 
> that expects a one-argument function parameter where the argument is a two element tuple.
> 
> I don’t think anyone disagrees that removing this functionality without 
> simultaneously providing a real destructuring feature regresses the usability of the 
> language where closures are concerned.

What if compiler in Swift 4 will be smart enough to generate correct *type* of 
provided closure depending of required type of function parameter *only* if closure 
defined inside the function call *and* has no type annotations for its arguments?

I mean, that having
func fooTuple(_ c: ((Int,Int))->Void) {..}
func fooParams(_ c: (Int,Int)->Void) {..}

, when we call
fooTuple {x,y in }
- compiler probably can generate closure of correct type ((Int,Int))->Void from this 
code.

and for
fooParams {x,y in }
- compiler can generate closure of type (Int,Int)->Void

But, I suggest this can be allowed only if there is no types specified for x,y. This 
is to reduce the ambiguity - we can't just declare the closure constant or func with 
syntax {x,y in } as we need types for x,y in this case, i.e.

let closure1 = {(x: Int, y: Int) in ..} // this is definitely (Int,Int)->()
let closure2 = {(x: (Int, Int)) in ..} // this is definitely ((Int,Int))->()

// let closure3 = {x, y in .. } // invalid syntax

//fooTuple(closure1) // invalid parameter type
//fooParams(closure2) // invalid parameter type
fooTuple {x,y in } // ok, ((Int,Int))->() closure will be generated
fooParams {x,y in } // ok, (Int,Int)->() closure will be generated

So, closure declared inside a func call without types assigned to closure's arguments 
- could be a very special case, when compiler will generate closure of needed type.

As I understand, such solution can dramatically reduce the problems with migration 
developers have. And also this will be Swift3 compatible.

> 
> Understanding other fallout from SE-0110 will be helpful in guiding the decision of 
> how to move forward from here.
> 
> Mark
> 
>>
>> Other aspects of the migration went quite smoothly.
>>
>> BTW, if I were at WWDC this year I would be in the Swift lab pestering them about 
>> this.  Hopefully that feedback is happening. :)
>>
>> Ray
>>
>>
>>> On Jun 6, 2017, at 8:22 AM, Shawn Erickson via swift-evolution 
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>>
>>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution 
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>>
>>>>     Le 6 juin 2017 à 15:30, Vladimir.S <svabox at gmail.com
>>>>     <mailto:svabox at gmail.com>> a écrit :
>>>>
>>>>     I'm just trying to understand your opinion.
>>>>     Let me know, what result do you *expect* for this Swift4 code given what
>>>>     SE-0066 requires for function types:
>>>>
>>>>     func foo(x : (Int, Int))->() {}
>>>>
>>>>     print(type(of: foo))  // ??
>>>>     print(foo is (_: Int, _: Int)->())  // ??
>>>
>>>     I couldn't care less.
>>>
>>>     What I care about: the code regressions introduced by SE-0110 (look at
>>>     previous messages in this long thread, and the ridiculous state of closures
>>>     that eat tuples), and the migration bugs (look at Xcode 9 release notes).
>>>
>>>
>>> Note that many of Apple's swift team are likely swamped with WWDC at the moment. 
>>> They are also dealing with merging out their private changes announced so far at 
>>> WWDC. Xcode 9 is prerelease still so expect things to get revised to some degree 
>>> before the final release.
>>>
>>> Not say to not voice concerns but at this time some patience will be needed.
>>>
>>> -Shawn
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>