Why is the status of SE-0110 "implemented"?


(Jens Persson) #1

I was notified that my SR-2216 and SR-296 had been "fixed as part of
implementing SE-0110".

But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot
2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)".

The title of SE-0110 is
"Distinguish between single-tuple and multiple-argument function types"

Keep that in mind while observing the following demonstration of the (Swift
4) behavior of Developer Snapshot 2017-06-02 (a):

func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
func g(_ tuple: (Int, Int)) { print("\(tuple)") }
f(1, 2) // 1, 2
g((1, 2)) // (1, 2)
// Working as expected.

// But:
print(type(of: f) == type(of: g)) // true
// IMHO this is not how to properly
// "Distinguish between single-tuple and multiple-argument function types"

// And as if that wasn't enough (pay close attention):
var (fCopy, gCopy) = (f, g)
fCopy(1, 2) // 1, 2
gCopy((1, 2)) // (1, 2)
swap(&fCopy, &gCopy)
fCopy(1, 2) // (1, 2)
gCopy((1, 2)) // 1, 2
// Crazy!

I'm trying to put this behavior and the following pieces together:

1. The introdoction from SE-0110:
"Swift's type system should properly distinguish between functions that
take one tuple argument, and functions that take multiple arguments."

2. The status of SE-0110:
Implemented (Swift 4)

3. The "fixed as part of implementing SE-0110" notification of my bug
reports
SR-2216: Confusing behavior related to closure types and tuples
SR-296: Fix inconsistencies related to tuples, arg/param lists, type
params, typealiases

Perhaps SE-0110 is just not fully implemented in dev snapshot 2017-06-02,
but it is implemented somewhere, why else should it get the status
"implemented"?

But then I read the following by Vladimir S (one of the SE-0110 authors?):
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036965.html

It's a very interesting read, and it's nice to see these old
inconsistencies are getting some attention (they deserve all the attention
they can get), but I'm still confused.

Is it possible to implement SE-0110 without sorting out the above
demonstrated inconsistencies?

Should status of SE-0110 really be "Implemented"?

/Jens


(John McCall) #2

I was notified that my SR-2216 and SR-296 had been "fixed as part of implementing SE-0110".

But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot 2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)".

Yes, the reflective type system does not yet properly distinguish these cases; it's a bug and will be fixed, but probably not before 4.0.

John.

···

On Jun 3, 2017, at 3:01 PM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

The title of SE-0110 is
"Distinguish between single-tuple and multiple-argument function types"

Keep that in mind while observing the following demonstration of the (Swift 4) behavior of Developer Snapshot 2017-06-02 (a):

func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
func g(_ tuple: (Int, Int)) { print("\(tuple)") }
f(1, 2) // 1, 2
g((1, 2)) // (1, 2)
// Working as expected.

// But:
print(type(of: f) == type(of: g)) // true
// IMHO this is not how to properly
// "Distinguish between single-tuple and multiple-argument function types"

// And as if that wasn't enough (pay close attention):
var (fCopy, gCopy) = (f, g)
fCopy(1, 2) // 1, 2
gCopy((1, 2)) // (1, 2)
swap(&fCopy, &gCopy)
fCopy(1, 2) // (1, 2)
gCopy((1, 2)) // 1, 2
// Crazy!

I'm trying to put this behavior and the following pieces together:

1. The introdoction from SE-0110:
"Swift's type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments."

2. The status of SE-0110:
Implemented (Swift 4)

3. The "fixed as part of implementing SE-0110" notification of my bug reports
SR-2216: Confusing behavior related to closure types and tuples
SR-296: Fix inconsistencies related to tuples, arg/param lists, type params, typealiases

Perhaps SE-0110 is just not fully implemented in dev snapshot 2017-06-02, but it is implemented somewhere, why else should it get the status "implemented"?

But then I read the following by Vladimir S (one of the SE-0110 authors?):
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036965.html

It's a very interesting read, and it's nice to see these old inconsistencies are getting some attention (they deserve all the attention they can get), but I'm still confused.

Is it possible to implement SE-0110 without sorting out the above demonstrated inconsistencies?

Should status of SE-0110 really be "Implemented"?

/Jens

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #3

Are you using the Swift 4 language mode?

<https://swift.org/blog/swift-4-0-release-process/#source-compatibility>

-- Ben

···

On 3 Jun 2017, at 23:01, Jens Persson wrote:

I was notified that my SR-2216 and SR-296 had been "fixed as part of implementing SE-0110".

But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot 2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)".

The title of SE-0110 is
"Distinguish between single-tuple and multiple-argument function types"

Keep that in mind while observing the following demonstration of the (Swift 4) behavior of Developer Snapshot 2017-06-02 (a):

func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
func g(_ tuple: (Int, Int)) { print("\(tuple)") }
f(1, 2) // 1, 2
g((1, 2)) // (1, 2)
// Working as expected.

// But:
print(type(of: f) == type(of: g)) // true
// IMHO this is not how to properly
// "Distinguish between single-tuple and multiple-argument function types"

// And as if that wasn't enough (pay close attention):
var (fCopy, gCopy) = (f, g)
fCopy(1, 2) // 1, 2
gCopy((1, 2)) // (1, 2)
swap(&fCopy, &gCopy)
fCopy(1, 2) // (1, 2)
gCopy((1, 2)) // 1, 2
// Crazy!

I'm trying to put this behavior and the following pieces together:

1. The introdoction from SE-0110:
"Swift's type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments."

2. The status of SE-0110:
Implemented (Swift 4)

3. The "fixed as part of implementing SE-0110" notification of my bug reports
SR-2216: Confusing behavior related to closure types and tuples
SR-296: Fix inconsistencies related to tuples, arg/param lists, type params, typealiases

Perhaps SE-0110 is just not fully implemented in dev snapshot 2017-06-02, but it is implemented somewhere, why else should it get the status "implemented"?

But then I read the following by Vladimir S (one of the SE-0110 authors?):
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036965.html

It's a very interesting read, and it's nice to see these old inconsistencies are getting some attention (they deserve all the attention they can get), but I'm still confused.

Is it possible to implement SE-0110 without sorting out the above demonstrated inconsistencies?

Should status of SE-0110 really be "Implemented"?

/Jens


(Jens Persson) #4

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@benrimmington.com> wrote:

Are you using the Swift 4 language mode?

<https://swift.org/blog/swift-4-0-release-process/#source-compatibility>

-- Ben

> On 3 Jun 2017, at 23:01, Jens Persson wrote:
>
> I was notified that my SR-2216 and SR-296 had been "fixed as part of
implementing SE-0110".
>
> But AFAICT SE-0110 can't possibly be fully implemented in dev snapshot
2017-06-02, even though the status of SE-0110 is "Implemented (Swift 4)".
>
>
> The title of SE-0110 is
> "Distinguish between single-tuple and multiple-argument function types"
>
> Keep that in mind while observing the following demonstration of the
(Swift 4) behavior of Developer Snapshot 2017-06-02 (a):
>
> func f(_ a: Int, _ b: Int) { print("\(a), \(b)") }
> func g(_ tuple: (Int, Int)) { print("\(tuple)") }
> f(1, 2) // 1, 2
> g((1, 2)) // (1, 2)
> // Working as expected.
>
> // But:
> print(type(of: f) == type(of: g)) // true
> // IMHO this is not how to properly
> // "Distinguish between single-tuple and multiple-argument function
types"
>
> // And as if that wasn't enough (pay close attention):
> var (fCopy, gCopy) = (f, g)
> fCopy(1, 2) // 1, 2
> gCopy((1, 2)) // (1, 2)
> swap(&fCopy, &gCopy)
> fCopy(1, 2) // (1, 2)
> gCopy((1, 2)) // 1, 2
> // Crazy!
>
> I'm trying to put this behavior and the following pieces together:
>
> 1. The introdoction from SE-0110:
> "Swift's type system should properly distinguish between functions that
take one tuple argument, and functions that take multiple arguments."
>
> 2. The status of SE-0110:
> Implemented (Swift 4)
>
> 3. The "fixed as part of implementing SE-0110" notification of my bug
reports
> SR-2216: Confusing behavior related to closure types and tuples
> SR-296: Fix inconsistencies related to tuples, arg/param lists, type
params, typealiases
>
>
> Perhaps SE-0110 is just not fully implemented in dev snapshot
2017-06-02, but it is implemented somewhere, why else should it get the
status "implemented"?
>
> But then I read the following by Vladimir S (one of the SE-0110
authors?):
> https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20170529/036965.html
>
> It's a very interesting read, and it's nice to see these old
inconsistencies are getting some attention (they deserve all the attention
they can get), but I'm still confused.
>
> Is it possible to implement SE-0110 without sorting out the above
demonstrated inconsistencies?
>
> Should status of SE-0110 really be "Implemented"?
>
> /Jens


(Ben Rimmington) #5

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@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@benrimmington.com> wrote:

Are you using the Swift 4 language mode?

<https://swift.org/blog/swift-4-0-release-process/#source-compatibility>

-- Ben


(Jens Persson) #6

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),

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@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@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@benrimmington.com> > wrote:
>>
>> Are you using the Swift 4 language mode?
>>
>> <https://swift.org/blog/swift-4-0-release-process/#source-compatibility
>
>>
>> -- Ben


(John McCall) #7

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.

···

On Jun 5, 2017, at 12:08 AM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

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@benrimmington.com <mailto:me@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@bitcycle.com <mailto:jens@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@benrimmington.com <mailto:me@benrimmington.com>> wrote:
>>
>> Are you using the Swift 4 language mode?
>>
>> <https://swift.org/blog/swift-4-0-release-process/#source-compatibility>
>>
>> -- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jens Persson) #8

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@apple.com> wrote:

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Mark Lacey) #9

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

···

On Jun 6, 2017, at 12:08 AM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

/Jens

On Tue, Jun 6, 2017 at 2:45 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@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 <me@benrimmington.com <mailto:me@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@bitcycle.com <mailto:jens@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@benrimmington.com <mailto:me@benrimmington.com>> wrote:
>>
>> Are you using the Swift 4 language mode?
>>
>> <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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #10

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

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 <rjmccall@apple.com >> <mailto:rjmccall@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 <me@benrimmington.com >>> <mailto:me@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@bitcycle.com <mailto:jens@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@benrimmington.com <mailto:me@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


(Mark Lacey) #11

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

···

On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox@gmail.com> wrote:

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 <rjmccall@apple.com <mailto:rjmccall@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 <me@benrimmington.com >>>> <mailto:me@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@bitcycle.com <mailto:jens@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@benrimmington.com <mailto:me@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


(Vladimir) #12

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)

···

On 06.06.2017 19:41, Mark Lacey wrote:

On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> >> wrote:

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> >>>> <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 <rjmccall@apple.com >>>> <mailto:rjmccall@apple.com> <mailto:rjmccall@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> >>>>> <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 <me@benrimmington.com >>>>> <mailto:me@benrimmington.com> >>>>> <mailto:me@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@bitcycle.com >>>>> <mailto:jens@bitcycle.com> <mailto:jens@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@benrimmington.com >>>>> <mailto:me@benrimmington.com> <mailto:me@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> <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> <mailto:swift-evolution@swift.org>
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


(Mark Lacey) #13

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

···

On Jun 6, 2017, at 11:09 AM, Vladimir.S <svabox@gmail.com> wrote:
On 06.06.2017 19:41, Mark Lacey wrote:

On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:

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> <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 <rjmccall@apple.com <mailto:rjmccall@apple.com> <mailto:rjmccall@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> <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 <me@benrimmington.com <mailto:me@benrimmington.com> >>>>>> <mailto:me@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@bitcycle.com <mailto:jens@bitcycle.com> <mailto:jens@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@benrimmington.com <mailto:me@benrimmington.com> <mailto:me@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> <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> <mailto:swift-evolution@swift.org>
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


(Jens Persson) #14

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@swift.org> wrote:

> On Jun 6, 2017, at 11:09 AM, Vladimir.S <svabox@gmail.com> wrote:
>
> On 06.06.2017 19:41, Mark Lacey wrote:
>>> On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox@gmail.com <mailto: > svabox@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@swift.org <mailto: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 <rjmccall@apple.com > <mailto:rjmccall@apple.com> <mailto:rjmccall@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> > <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 < > me@benrimmington.com <mailto:me@benrimmington.com> > >>>>>> <mailto:me@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@bitcycle.com > <mailto:jens@bitcycle.com> <mailto:jens@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@benrimmington.com <mailto:me@benrimmington.com> <mailto: > me@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-
>>
>>>>>> >>
>>>>>> >> -- Ben
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org <mailto: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>
<mailto:swift-evolution@swift.org>
>>>>> 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


(Mark Lacey) #15

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

Thanks!

Mark

···

On Jun 6, 2017, at 3:16 PM, Jens Persson <jens@bitcycle.com> wrote:

/Jens

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

> On Jun 6, 2017, at 11:09 AM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:
>
> On 06.06.2017 19:41, Mark Lacey wrote:
>>> On Jun 6, 2017, at 4:00 AM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com> <mailto:svabox@gmail.com <mailto:svabox@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/> <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 (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@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto: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 <rjmccall@apple.com <mailto:rjmccall@apple.com> <mailto:rjmccall@apple.com <mailto:rjmccall@apple.com>> <mailto:rjmccall@apple.com <mailto:rjmccall@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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto: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 <me@benrimmington.com <mailto:me@benrimmington.com> <mailto:me@benrimmington.com <mailto:me@benrimmington.com>> > >>>>>> <mailto:me@benrimmington.com <mailto:me@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@bitcycle.com <mailto:jens@bitcycle.com> <mailto:jens@bitcycle.com <mailto:jens@bitcycle.com>> <mailto:jens@bitcycle.com <mailto:jens@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@benrimmington.com <mailto:me@benrimmington.com> <mailto:me@benrimmington.com <mailto:me@benrimmington.com>> <mailto:me@benrimmington.com <mailto:me@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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto: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> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>> <mailto: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 <mailto:swift-evolution@swift.org> <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution