> On Jun 6, 2017, at 4:00 AM, Vladimir.S <sva...@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.
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@swift.org <mailto:swift-evolution@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 <rjmcc...@apple.com
>>> <mailto:rjmcc...@apple.com>> wrote:
>>>
>>>> On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@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 <m...@benrimmington.com
>>>> <mailto:m...@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 <j...@bitcycle.com
>>>> <mailto:j...@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
>>>> <m...@benrimmington.com <mailto:m...@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@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <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
