> On Jun 6, 2017, at 11:45 AM, Vladimir.S <[email protected]> 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
>>> <[email protected] <mailto:[email protected]>> 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.
> //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
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>> On Tue, Jun 6, 2017 at 7:18 AM Gwendal Roué via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>> Le 6 juin 2017 à 15:30, Vladimir.S <[email protected]
>>>>> <mailto:[email protected]>> 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
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
