Type aliases should be scoped to the containing type

[ilyapuchka]

With current implementation type aliases with the same name defined in different types will override each other. That breaks the usual case of defining type alias to conform to protocol.

struct Foo {}
enum FooEnum: RawRepresentable {
  typealias RawValue = Foo
  var rawValue: RawValue { ... }
}

struct Bar {}
enum BarEnum: RawRepresentable {
  typealias RawValue = Bar
  var rawValue: RawValue { ... }
}

In this case type of rawValue property of FooEnum will be detected incorrectly as Bar as RawValue = Bar will override RawValue = Foo

[krzysztofzablocki]

my changes in #39 will help since we will be able to access parent types from children, I've few ideas how we can implement this but not sure if you started on this or is this for the picking?

[ilyapuchka]

I didn't start on that, just though about how to implement that so you can pick it if you want. What were your ideas?

I was thinking that to parse type aliases inside the type is not a big deal, we just need to get a syntax map for not the whole content, but just for the type body portion. Then we can store discovered type aliases in the collection in the Type just the same way as inherited types. This way it will be possible to find types for type names "MyType.MyAlias" later.

The problem then is how to parse global type aliases. Probably we need to check if typealias token is outside of any types body ranges (I guess we can get that from __parserData).

Another problem is what to do with private type aliases. The thing is that it's possible to have different private typealiases with the same name in different extensions.

struct MyStruct {}

extension MyStruct {
    private typealias MyAlias = Int
    private var myInt: MyAlias { return 0 }
}

extension MyStruct {
    private typealias MyAlias = String
    private var myString: MyAlias { return "" }
}

So to find proper type in this case we need to do that before we extend type with these extensions... But to be honest I'm not sure we should handle that case as these variables will not be accessible from generated code. But then maybe we should ignore everything what is private? Like private methods, variables, contained types.
Also we should probably only process type aliases defined on a type level.
And another thing to think about - generic type aliases which are now possible in Swift 3...

[krzysztofzablocki]

Pretty much the same idea, it seems you have thought this through more than I did though, want to try this out? I think it makes sense to skip scanning private variables since you are right they wouldn't be accessible, if it's not private variable but has private typealias we can replace it with right type then

[ilyapuchka]

Ok, I'll go for it then.
If it's private type alias we can not use it for anything but private variables, or only in private methods, so we can simply ignore all the private stuff.

[krzysztofzablocki]

ah right, it doesn't compile otherwise 👍