I think we currently check this at parse-time, so we'd have to either move the check to Sema (type-checking) or make it smarter / more lax without accidentally allowing closure self-reference.

Looks like this is still outstanding. We just ran into this in PR-16238 with

let type = type(of: value:)

Not sure if there's much we can do about this now, but this would still be nice.

You generally have the workaround of using the module name to disambiguate (Swift.type(of: value)).

Yep, and that's what we're using. 🙂 Still, seems like something that could be made better in cases where it's intuitively clear to the reader that this is not ambiguous (e.g. in almost all cases not involving closures).

Comment by Rufus Neumann (JIRA)

A related problem is when you try to redefine a binding, e.g.

let foo: Int? = 1 // note: 'foo' previously declared here
let foo: Int = foo! // error: variable used within its own initial value, error: invalid redeclaration of 'foo'

Possible workaround:

let foo: Int = {
    let foo: Int? = 1
    return foo!
}()

Just hit this (again - hit it the first time in SR-5916 and had forgotten) and was very confused by it. The workaround mentioned by @belkadan above doesn't work when you're calling a private function, and even when it does work it's non-obvious and aesthetically unpleasing 🙁

It looks like this bug has been "In Progress" since May 2017. Since rmnblm (JIRA User)'s profile has been inactive since then, I'm moving this back to Unassigned and Open for someone to pick up.

For the case in SR-5916, you'd use self.foo, but yeah.

This is probably a related issue:

func foo() -> Int { return 1}
func whatever() {    
     let foo = 5    
     let foo1 = foo()     // Error: Cannot call value of non function type Int
}

The compiler doesn't seem to recognize that foo() is a function in scope and not a variable.

I run into these two errors frequently.

The number of duplicate bug reports indicates this is a common pain point.

That's more of SR-1687.

How does a variable shadow a function?

Anyway, more like https://bugs.swift.org/browse/SR-9096

Comment by Lennart Stolz (JIRA)

If I get the author's (ayaka (JIRA User)) intention right, this issue should be resolved by these changes:

Remove parse-time name lookup by @slavapestov.

The following test case covers this case:

test/NameLookup/name_lookup.swift#L661-L664