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-1976] Closure signature in Swift 3 required for inout params #44585

Closed
swift-ci opened this issue Jul 3, 2016 · 5 comments
Closed

[SR-1976] Closure signature in Swift 3 required for inout params #44585

swift-ci opened this issue Jul 3, 2016 · 5 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Jul 3, 2016

Previous ID SR-1976
Radar None
Original Reporter erica (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug
Assignee erica (JIRA)
Priority Medium

md5: 5e016df9563a1b6894b80711441939f1

is duplicated by:

  • SR-3632 Swift is unable to properly infer the type of closures with inout parameters without specific type information.

relates to:

  • SR-3520 Generic function taking closure with inout parameter can result in a variety of compiler errors or EXC_BAD_ACCESS

Issue Description:

For whatever reason, you have to declare the closure signature with inout variables in Swift 3. You didn't in Swift 2. Example below. Also affected the new stdlib sequence functions.

Swift 2:

func myFor<T>(args: T, _ test: (T) -> Bool, _ next: (inout T) -> Void, body: (inout T) -> Void) {
    var state = args
    while test(state) {
        defer { next(&state) } ; body(&state)
    }
}

myFor(0, { $0 < 10 }, { $0 += 2 }) {
    print($0)
}

Swift 3:

func myFor<T>(_ args: T, _ test: (T) -> Bool, _ next: (inout T) -> Void, body: (inout T) -> Void) {
    var state = args
    while test(state) {
        defer { next(&state) } ; body(&state)
    }
}

myFor(0, { $0 < 10 }, { (i: inout Int) in  return i += 2 }) {
    print($0)
}
@belkadan
Copy link
Contributor

belkadan commented Jul 5, 2016

Hm. I don't remember this ever working, even in Swift 2. (I believe you that it compiled, but I also remember getting errors sometimes, which makes me think it may not have been implemented correctly.) @slavapestov, do you know what changed here?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jul 5, 2016

Comment by erica sadun (JIRA)

Just for the record:

Also, I'd really like this not to be a requirement: is there a solid language reason for making it hard to use closures with inout?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jul 5, 2016

Comment by erica sadun (JIRA)

Changing code to the following works in Swift 3/Xcode 8 (thanks Mike Ash):

func myFor<T>(_ args: T, _ test: (T) -> Bool, _ next: (inout T) -> Void, body: (inout T) -> Void) {
    var state = args
    while test(state) {
        defer { next(&state) } ; body(&state)
    }
}

myFor(0, { $0 < 10 }, { $0 = $0 + 2 }) {
    print($0)
}

So it may be an issue with +=

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jul 5, 2016

Comment by erica sadun (JIRA)

Further: Mike Ash offers this, which crashes too:

func myFor<T>(_ args: T, _ test: (T) -> Bool, _ next: (inout T) -> Void, body: (inout T) -> Void) {
    var state = args
    while test(state) {
        defer { next(&state) } ; body(&state)
    }
}

let plusEquals: (inout Int, Int) -> Void = (+=)
myFor(0, { $0 < 10 }, { plusEquals(&$0, 2) }) {
    print($0)
}

@rudkx
Copy link
Member

rudkx commented Jan 9, 2017

Fixed on master with this merge: c04c6c9

Please confirm with a build that has this fix in it and close the issue if you agree the issue is fixed.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants