> On Jun 6, 2017, at 11:09 AM, Vladimir.S <[email protected]> wrote: > > On 06.06.2017 19:41, Mark Lacey wrote: >>> On Jun 6, 2017, at 4:00 AM, Vladimir.S <[email protected] >>> <mailto:[email protected]>> 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)
Thanks! Mark > >> 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 >>>>> <[email protected] <mailto:[email protected]> >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]> <mailto:[email protected]>> wrote: >>>>> >>>>>> On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution >>>>>> <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]> >>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected]>> 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 >>>>>> <[email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected]>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
