[swift-evolution] Revisiting SE-0110

Vladimir.S svabox at gmail.com
Tue Jun 6 10:23:40 CDT 2017


On 06.06.2017 16:53, Víctor Pimentel Rodríguez wrote:
> On Tue, Jun 6, 2017 at 3:30 PM, Vladimir.S via swift-evolution 
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>     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)->())  // ??
> 
> 
>     Vladimir.
> 
> 
> I think most developers would not care about or notice that discrepancy, while most 
> will encounter the regression in closures and specially in the Dictionary API. In 
> fact most developers will have this reaction:
> 
> https://owensd.io/2017/06/01/se-110-fallout-im-confused/
> 
> Please, I don't mean that the type discrepancy should not be changed or that the 
> proposals have not value, it's just a matter of priorities here.

SE-0066 and SE-0110 was reviewed and accepted to be implemented for *Swift 3*, but 
due to some reasons they were not (fully) implemented and were delayed for Swift 4. 
SE-0110 was not just brought the last minute before release for Swift 4. So I 
personally don't understand about which 'priorities' you thinking about.

Also please note that after Swift 4 is released, it seems like we will not be able to 
fix the function types for long time because of source compatibility rules.

And I just want again point out, as I understand, that function type inconsistency 
*should* be fixed by *SE-0066*, not SE-0110. SE-0110 just follows the way.

All I'm trying to find out(from core team, actually) *what will be the result of this 
code in Swif4 Release due to requirements of SE-0066(!)* :

func foo(x : (Int, Int))->() {}

print( type(of: foo) )  // ??
print( foo is (_: Int, _: Int)->() )  // ??
print( ( (_: Int, _: Int)->() ).self == ( ((Int,Int))->() ).self ) // ??

As I understand, *this* is the main point actually. Please follow my reasoning:

* If type(of: foo) will be still(as currently) (Int,Int)->() , then I have a question 
if SE-0066 actually be *fully* implemented in Swift 4 *or* core team decided to 
revisit SE-0066 or decided to implement it only partially.
   If they decided to revert SE-0066 or implement partially, then I don't understand 
the whole point of introduced complexity for function types, why we need separate 
type for function with single tuple if it is not reflected in type system. And *in 
this case* I also don't see any sense in SE-0110 because IMO type system for function 
types will still be broken.

* But, if type(of: foo) will be ((Int,Int))->() as expected, then we have this 
situation: some function can require a parameter of function type ((Int,Int))->() and 
we want to provide (Int,Int)->() to it.  So, we have to answer to these questions:

   1. What is the type of {(x: Int, y: Int) in } and {(x: (Int,Int)) in } closures ? 
I expect they must be (Int,Int)->() and ((Int,Int))->() accordingly.

   2. What is the type of {x,y in } if it is defined inside func call where argument 
of type ((Int,Int))->() is expected ? If {x,y in} can be treated as different type 
depends on context, can {(x,y) in } also ? can {(x: Int, y: Int) in} also?

   3. Can we just send instance of type (Int,Int)->() when ((Int,Int))->() is 
required, i.e. will we allow implicit conversion between such specific function types 
in all contexts?

   4. If we are not going to allow implicit conversion, what syntax we introduce to 
destructure tuple argument in closure or just disallow calling the function with 
wrong closure type(the latter was accepted as SE-0110).

Note, that if  type(of: foo) will be '((Int,Int))->()' in Swift 4 - we just have no 
option to 'just' drop SE-0110 without answering the above questions, because we have 
a situation when parameter(closure) of wrong type is provided.

Of course, I support any solution that allows compact code to destructure tuple 
argument in closure, but with strong respect of correct function types in Swift 4.

Actually I do feel like I'm missing something important about function types in Swift 
4, SE-0066 and SE-0110 and continue to fight with a wind, so I'll be glad  someone 
points me to correct direction :-)

Vladimir.

> 
> -- 
> Víctor Pimentel


More information about the swift-evolution mailing list