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

Jens Persson jens at bitcycle.com
Tue Jun 6 17:16:53 CDT 2017 

Here are the four you asked me to report:

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
Don't allow swapping a single-tuple function with a multiple-argument
function

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
Single-tuple and multiple-argument function types should be treated as
different types

/Jens


On Tue, Jun 6, 2017 at 8:17 PM, Mark Lacey via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 6, 2017, at 11:09 AM, Vladimir.S <svabox at gmail.com> wrote:
> >
> > 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)
>
> 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 <
> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/1b69d5ef/attachment.html>

More information about the swift-evolution mailing list