Cannot find type 'Bar' in scope, in extension

Using Swift
1

Given:

struct Foo {
}

extension Foo {
    struct Bar {
    }
}

The following, innocent looking, extension produces the error: Cannot find type 'Bar' in scope

extension Foo.Bar {
    static func bar () -> Bar { // Error: Cannot find type 'Bar' in scope
        Bar ()
    }
}

However, using a typealias solves the problem.

extension Foo.Bar {
    typealias Bar = Foo.Bar

    static func bar () -> Bar { // Okay
        Bar ()
    }
}

I can't see it. Can anyone illuminate the reason for the error?

Aren't these equivalent?

extension Foo {
    struct Bar {
        static func bar () -> Bar {
            Bar ()
        }
    }
}

extension Foo.Bar {
    static func bar () -> Bar {
        Bar ()
    }
}
2

That is strange. Your solution with the typealias might reveal why it's happening. The compiler is probably looking for the name Foo.Bar.Bar since you're in Bar's scope, and when it can't find that it throws that error. By making the typealias, you're creating a type Foo.Bar.Bar. In this case though it would be pretty trivial to just swap Bar for Self, which should work. Or, you can use fully-qualified names:

extension Foo {
  public static func bar() -> Foo.Bar {
    Foo.Bar()
  }
}
3

Name lookup in Swift is lexical: when you’re in the original declaration of Bar, name lookup looks in Bar, then the lexically-containing Foo (whether it’s an extension of Foo or not), then the top level. When you’re in an extension, the lookup looks in Bar (the current type), then the top level, cause that’s what contains the extension declaration.

It wouldn’t have to work this way, but (1) changing this would be source-breaking, so we’d have to have a strong motivation and limit it to a new language mode; and (2) with the current rules, moving a type in or out of another type, or from one parent type to another, can be a source-compatible change as long as you leave a typealias behind, and changing the lookup rules here would break that.

5 Likes
4

Note that you could use "Self" instead of "Bar" in that context: within "extension Foo.Bar" "Self" would mean "Bar".

1 Like
5

@tera and @jrose, thank you for the educational nudges. :slight_smile:

It is good to know that , surprisingly, Self resolves to Bar, in the extension:

struct Foo {    
}

extension Foo {
    struct Bar {
    }
}

extension Foo.Bar {
    static func bar () -> Self {
        return Self ()
    }
}
6

I'm curious to know: why is this surprising? Is there some other behavior that you think users would expect from Self here?

1 Like
7

Because as @jrose explained, name lookup in Swift is lexical. As a result the following code fails to compile:

extension Foo.Bar {
    static func bar () -> Bar { // Error
        return Self ()
    }
}

but this doesn't:

extension Foo.Bar {
    static func bar () -> Self { // Okay
        return Self ()
    }
}

To me this is surprising because I thought Self and Bar were equivalent in this context. Maybe there is something else I am missing here.

8

"if Self and Bar are equivalent how come I can use one but not another?!" :crazy_face:
Well, they are not fully equivalent...

When you "cd" into a folder "/Users/joe/Desktop/Foo/Bar" and try to do "ls Bar" - that won't work (assuming you don't have another "Bar" in there!), although your could still do "ls .", similar to Self. To do "ls Bar" you'd need to step out of "Bar" into "Foo", but then "mkdir", etc would create items not where you want (you want them in "Bar").

If you "cd" into "Foo" you could type "mkdir Bar/bar" to make a directory inside "Bar". I hope we'd have the equivalent in Swift one day:

func Bar.bar() { ... }
2 Likes