Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-5112] Not correct function types in Swift4 (typeof) #47688

Open
swift-ci opened this issue Jun 6, 2017 · 5 comments
Open

[SR-5112] Not correct function types in Swift4 (typeof) #47688

swift-ci opened this issue Jun 6, 2017 · 5 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Jun 6, 2017

Previous ID SR-5112
Radar rdar://problem/32601617
Original Reporter VladimirS (JIRA User)
Type Bug
Environment

swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-01-a-osx

Additional Detail from JIRA
Votes 1
Component/s
Labels Bug
Assignee @xedin
Priority Medium

md5: e265814eeaa6d3f294a7315eed219f29

is blocked by:

  • SR-5127 Single-tuple and multiple-argument function types should not be considered equal

is duplicated by:

  • SR-5129 Don't treat func signatures as being the same when they are in fact different

Issue Description:

Mark Lacey <mark.lacey@apple.com> asked to create this issue.

I believe fooParam should have type of (Int,Int) -> () and fooTuple of type ((Int,Int)) -> (), but it seems like they have the same type:

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

//--- closure ---

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) -> ()
@rudkx
Copy link
Member

rudkx commented Jun 7, 2017

@swift-ci create

@rudkx
Copy link
Member

rudkx commented Jun 7, 2017

For

  func fooTuple(_ x: (Int, Int)) {}
  let t = type(of: fooTuple)

we maintain the fact that it’s a function taking a tuple through the AST passes, but it looks like the SIL metatype instruction treats it like a function taking two arguments.

I suspect this is simply a result of canonicalizing the type when generating SIL.

@belkadan
Copy link
Contributor

belkadan commented Jun 7, 2017

We've also historically had problems printing function types. @slavapestov, @jckarter?

@jepers
Copy link

jepers commented Jun 7, 2017

Also, note that:

typealias A = (Int, Int) -> ()
typealias B = ((Int, Int)) -> ()

print(A.self == B.self) // true

func representsSameType<T>(_: T.Type, _: T.Type) -> Bool { return true }
func representsSameType<T, U>(_: T.Type, _: U.Type) -> Bool { return false }
print(representsSameType(A.self, B.self)) // true

func takesOnlyA(_: A.Type) { print("A!") }
takesOnlyA(A.self) // A!
takesOnlyA(B.self) // A!

Result is the same with (Swift 4) 2017-06-06 snapshots and Xcode 8.3.3 default toolchain.

@slavapestov
Copy link
Member

Yeah, the current implementation of SE-0110 does not fully address this. Runtime types are still canonicalized. We need to represent FunctionType as having an argument list and a result, instead of a single input and a result, so that single-argument function types canonicalize properly.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

No branches or pull requests

5 participants