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-2362] Compiler doesn't ask for explicit self in local function passed as @escaping #44969

Open
mattneub opened this issue Aug 16, 2016 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@mattneub
Copy link

Previous ID SR-2362
Radar None
Original Reporter @mattneub
Type Bug
Environment

Xcode Version 8.0 beta 6 (8S201h)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 5d150b756a45847a9f3a4d7cab69f1c4

relates to:

  • SR-2274 Nested functions should allow escaping attributes, be @NoEscape by default

Issue Description:

Consider this:

func funcPasser(f:@escaping ()->()) -> () -> () {
    return f
}
class MyClass {
    var name = "matt"
    func test() {
        func f() {
            print(name)
        }
        let f2 = funcPasser(f:f)
        f2()
    }
}

Now, maybe I'm wrong, but it seems to me that the compiler should be complaining about the bare `name`. It should be insisting that I say `self.name`. I am handling `f` in a way that will capture `self` and preserve it, and the compiler knows this, because `funcPasser` has a `@escaping` parameter. If this were an anonymous trailing closure, the compiler would insist that I say `self`, so why doesn't it insist on it here?

@mattneub
Copy link
Author

@belkadan I don't think this has to do with being a local function. I can write the example this way:

class MyClass2 {
    var name = "matt"
    func f() {
        print(name)
    }
    func test() {
        let f2 = funcPasser(f:f)
        f2()
    }
}

@belkadan
Copy link
Contributor

I consider these two separate issues. The former captures self as soon as f is created; the latter has an f that's independent of any particular instance, and then partially applying it. More concretely, the self. requirement would go on name in the first example and on f in the second.

@Dante-Broggi
Copy link
Contributor

This still occurs in the Xcode 10 toolchain.

@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. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants