> On Jun 6, 2017, at 8:42 AM, Ray Fix via swift-evolution
> <[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.
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
>> <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
