On 07.06.2017 0:45, Mark Lacey wrote:
On Jun 6, 2017, at 11:45 AM, Vladimir.S <sva...@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@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?
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@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
