[swift-evolution] Revisiting SE-0110

Tue Jun 6 17:40:55 CDT 2017

On 07.06.2017 0:45, Mark Lacey wrote:
> 
>> On Jun 6, 2017, at 11:45 AM, Vladimir.S <svabox at gmail.com> wrote:
>>
>> 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?
> 
> It might be possible to get something like this working.
> 
>> 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
> 
> It would be source breaking to not allow this to work in the cases where it does today. We would have to consider this as a function taking two arguments.
> 

Yes, my fault. Missed that Swift is smart enough even for this:
func foo(_ x: Int, _ y: Int) {}
let c = {x,y in foo(x,y)}  // ok, (Int,Int)->()

Btw, what do you think, is it possible to "just allow" accepting of closure/func with 
list of arguments where closure with one tuple argument is required(in case arguments 
and their types are matched and func/closure has no modifiers like 'inout' etc)?
I.e. accept func/closure of type (Int,Int)->() in *all* places where ((Int,Int))->() 
is required?
I mean, in this case one function type is expected, we provide another function type 
without any explicit conversion, can this be easily implemented in Swift 4 and will 
such rule be foreign for Swift's types system? Or it looks like it is more reasonable 
to provide special syntax/conversion for tuple destructuring for both closures and 
free funcs?

Vladimir.

>> //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.
> 
> Yes, if something like this could be implemented robustly it would make the cases where a closure is immediately passed as an argument to a function call work and allow most Swift 3 code to continue working.
> 
> Mark
> 
>>
>>> 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
> 
> 