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

Tue Jun 6 13:09:45 CDT 2017

On 06.06.2017 19:41, Mark Lacey wrote:
> 
>> On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>> 
>> wrote:
>>
>> 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)->()
> 
> Can you open two reports at bugs.swift.org <http://bugs.swift.org>, one for the ‘is’ 
> issue, and one for type(of:)?
> 
> These (along with the issue with function declarations that Jens mentioned) are all 
> similar issues, but each is in a different part of the compiler.

Here they are:
https://bugs.swift.org/browse/SR-5114  (typeof)
https://bugs.swift.org/browse/SR-5112  (is)

> 
> Mark
> 
> 
>>
>> 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> 
>>>> <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> <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> 
>>>>> <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>
>>>>>    <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> <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> <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> 
>>>>> <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> 
>>>> <mailto:swift-evolution at swift.org>
>>>> 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
>