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

[Jens Persson]

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)) -> ()") }

// 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 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?

/Jens




On Tue, Jun 6, 2017 at 2:45 AM, John McCall <rjmccall at apple.com> wrote:

> On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution <
> 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>
> 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> 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>
>> wrote:
>> >>
>> >> Are you using the Swift 4 language mode?
>> >>
>> >> <https://swift.org/blog/swift-4-0-release-process/#source-co
>> mpatibility>
>> >>
>> >> -- Ben
>>
>
> _______________________________________________
> 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/20170606/5c868ef2/attachment.html>