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