[swift-evolution] Why is the status of SE-0110 "implemented"?

Tue Jun 6 06:00:10 CDT 2017

Mark, could you please also comment this inconsistencies / bugs :
(swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx)

func fooParam(_ x: Int, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}

print("type of fooParam is", type(of:fooParam))
// result: type of fooParam is (Int, Int) -> ()

print("type of fooTuple is", type(of:fooTuple))
// result: type of fooTuple is (Int, Int) -> ()

print("type of fooTuple as (_:(Int,Int))->Void is", type(of: fooTuple as 
(_:(Int,Int))->()))
// result: type of fooTuple as (_:(Int,Int))->() is (Int, Int) -> ()

print("type of fooParam == type of fooTuple ?", type(of: fooParam) == type(of: fooTuple))
// result: true

if fooParam is (_: (Int,Int))->() { print("fooParam is (_: (Int,Int))->()") }
// result: fooParam is (_: (Int,Int))->()

if fooTuple is (Int,Int)->() { print("fooTuple is (Int,Int)->()") }
// result: fooTuple is (Int,Int)->()

var closureParam = { (x: Int, y: Int) in  }
var closureTuple = { (x: (Int, Int)) in  }

print("type of closureParam is", type(of:closureParam))
// result: type of closureParam is (Int, Int) -> ()

print("type of closureTuple is", type(of:closureTuple))
// result: type of closureTuple is (Int, Int) -> ()

if closureParam is (_: (Int,Int))->() { print("closureParam is (_: (Int,Int))->()") }
// result: closureParam is (_: (Int,Int))->()

if closureTuple is (Int,Int)->() { print("closureTuple is (Int,Int)->()") }
// result: closureTuple is (Int,Int)->()

Thank you.
Vladimir.

On 06.06.2017 11:43, Mark Lacey via swift-evolution wrote:
> 
>> On Jun 6, 2017, at 12:08 AM, Jens Persson via swift-evolution 
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> IMHO There seems to be a lot of bugs and inconsistencies left in more than just the 
>> reflective type system, for example the following won't compile although the two 
>> foo funcs clearly take different types as argument:
>>
>> func foo(fun: (Int, Int) -> ()) { print("was given a function of type: (Int, Int) 
>> -> ()") }
>> func foo(fun: ((Int, Int)) -> ()) { print("was given a function of type: ((Int, 
>> Int)) -> ()") }
> 
> I took a look at this. When determining if we have conflicting declarations, we 
> compute an interface type and this computation is stripping the parens around the 
> tuple in the second example, resulting in these two signatures appearing to be the 
> same, despite the fact that the types of the arguments to the two functions are 
> different.
> 
>> // This will result in error: invalid redeclaration of 'foo(fun:)'
>>
>> I would expect this to compile, and I can't understand how this has anything to do 
>> with the reflective type system.
>>
>>
>> Here is another example:
>>
>> func add(_ a: Int, _ b: Int) -> Int { return a + b }
>> let a: (Int, Int) -> Int = add
>> let b: ((Int, Int)) -> Int = add // This is OK, unexpectedly
> 
> I didn’t have a chance to look at this yet. I suspect this is related to the swap 
> example that you gave previously.
> 
>> I would not expect it to compile since the add func does not have the type ((Int, 
>> Int)) -> Int.
>> I don't think that is a dynamic cast, is it?
> 
> Would you mind opening bugs for all four issues - the two mentioned above and the two 
> from the previous e-mail (with type(of:) and swap examples)? Despite the fact that 
> some of these might have different underlying causes it would be useful to have 
> separate bugs and if they turn out to be the same issue we can dup as appropriate.
> 
> Mark
> 
>>
>> /Jens
>>
>>
>>
>>
>> On Tue, Jun 6, 2017 at 2:45 AM, John McCall <rjmccall at apple.com 
>> <mailto:rjmccall at apple.com>> wrote:
>>
>>>     On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution
>>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>     So the bug in the reflective type system needs to be fixed before SE-0110 can
>>>     actually be implemented (so that the statements in its title and text are true
>>>     when compared to the actual behavior of the current Swift 4 compiler), 
>>
>>     Gaps in the reflective type system are bugs, but they are not showstopper
>>     bugs.  We do not even expose any way to query the reflective system today; it
>>     basically only affects type equality and dynamic casts that programmers are
>>     very unlikely to use.  The changes in call type-checking are vastly more
>>     important, are implemented (modulo bugs, of course), and by themselves warrant
>>     calling SE-0110 implemented.
>>
>>     John.
>>
>>>
>>>     And yet:
>>>
>>>     1. The status of SE-0110 is "Implemented"
>>>
>>>     2. These statuses of the following issues are "resolved":
>>>         SR-2008: Distinguish between single-tuple and multiple-argument function types
>>>         SR-2216: Confusing behavior related to closure types and tuples
>>>         SR-296: Fix inconsistencies related to tuples, arg/param lists, type
>>>     params, typealiases
>>>
>>>     Why?
>>>
>>>     /Jens
>>>
>>>
>>>     On Sun, Jun 4, 2017 at 5:49 PM, Ben Rimmington <me at benrimmington.com
>>>     <mailto:me at benrimmington.com>> wrote:
>>>
>>>         I assumed that Swift 3 mode would be the default, so that existing
>>>         `#!/usr/bin/swift` scripts continue to work.
>>>
>>>         -- Ben
>>>
>>>         > On 3 Jun 2017, at 23:47, Jens Persson <jens at bitcycle.com <mailto:jens at bitcycle.com>> wrote:
>>>         >
>>>         > Yes of course, try my demonstration code yourself.
>>>         > (In the current dev snapshots, -swift-version 4 is the default and -swift-version 3 is what you need to set if you want 3 compability)
>>>         >
>>>         >> On Sun, Jun 4, 2017 at 12:37 AM, Ben Rimmington <me at benrimmington.com <mailto:me at benrimmington.com>> wrote:
>>>         >>
>>>         >> Are you using the Swift 4 language mode?
>>>         >>
>>>         >> <https://swift.org/blog/swift-4-0-release-process/#source-compatibility
>>>         <https://swift.org/blog/swift-4-0-release-process/#source-compatibility>>
>>>         >>
>>>         >> -- Ben
>>>
>>>
>>>     _______________________________________________
>>>     swift-evolution mailing list
>>>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>     https://lists.swift.org/mailman/listinfo/swift-evolution
>>>     <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 