> On Jun 6, 2017, at 3:16 PM, Jens Persson <[email protected]> wrote: > > Here are the four you asked me to report: > > https://bugs.swift.org/browse/SR-5127 <https://bugs.swift.org/browse/SR-5127> > Single-tuple and multiple-argument function types should not be considered > equal > > https://bugs.swift.org/browse/SR-5128 <https://bugs.swift.org/browse/SR-5128> > Don't allow swapping a single-tuple function with a multiple-argument function > > https://bugs.swift.org/browse/SR-5129 <https://bugs.swift.org/browse/SR-5129> > Don't treat func signatures as being the same when they are in fact different > > https://bugs.swift.org/browse/SR-5130 <https://bugs.swift.org/browse/SR-5130> > Single-tuple and multiple-argument function types should be treated as > different types
Thanks! Mark > > /Jens > > > On Tue, Jun 6, 2017 at 8:17 PM, Mark Lacey via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On Jun 6, 2017, at 11:09 AM, Vladimir.S <[email protected] > > <mailto:[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]> <mailto:[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/> > >> <http://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 > > <https://bugs.swift.org/browse/SR-5114> (typeof) > > https://bugs.swift.org/browse/SR-5112 > > <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] <mailto:[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] > >>>>> <mailto:[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] <mailto:[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] <mailto:[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] > >>>>>> <mailto:[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] <mailto:[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> > >>>>>> > >>>>>> <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] <mailto:[email protected]>> > >>>>>> <mailto:[email protected] <mailto:[email protected]>> > >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >>>>>> <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] <mailto:[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] <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]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
