About type aliases in protocol extensions: is this a bug?

Using Swift
1

I would like to know whether this is a bug.
Here, the typealias imposes a same-type constraint on A

protocol P {associatedtype A}
extension P {typealias A = Int}

While this is already an error

protocol P {
  associatedtype A
  func foo() -> A // 'A' is ambiguous for type lookup in this context
}
extension P {typealias A = Int}

Would appreciate feedback from the core team on this.
If this is a bug, what is the intended behavior?

If you want to discuss if it should or should not be a bug, please move to this thread.

1 Like
2

I'm certainly sure this is not a bug, but just something that we have never really diagnosed. There is a similar case in the qualified lookup thread.

In that sense, we should diagnose such cases better and ban them altogether.

3

My proposal is different, but nevertheless, if it really isn't a bug, that's great news.

4

It's fairly similar to the cases I mention in the lookup thread, not the same though. In my case it's obvious that typealias is shadowing a different type which makes referencing it impossible. In your case you're creating undiagnosed type collisions (as far as I understand it). I as non-compiler developer would say we need to diagnose all of such edge cases and simply ban them, because those are source of bugs and do not serve any good purpose.

To contrast your example:

struct P<A> {}
extension P {
  typealias A = Int // currently valid but should be banned
}
1 Like
5

That's a bit different because we are talking about protocols and their extensions (declarations in protocol extensions do not conflict with requirements).
Thanks for the feedback though! Let's not go too deep on discussing whether it is or isn't a bug. I think @Douglas_Gregor should have an answer to this.

6

I consider this a bug. We should resolve to the associated type. My apologies for not getting to review your proposal to clarify the interaction between typealiases and protocols yet.

  • Doug
1 Like
7

@DevAndArtist Do you have a SR for this?

8

Not yet, I was planning to start writing a draft this weekend. You can always check this thread for updates.

9

I don't think this should be left lurking in earlier versions. Let's file a bug and make the case a redeclaration error for < Swift 5. If by chance your proposal gets implemented in 4.2 we can override the condition to < 4.

But wait, the abilities you propose don't affect that case, it's an ambiguity anyway, right?

10

Can you explain what you mean by that? I'm not sure if it's possible to retrofit that to previous versions of the compiler. (I could be wrong though.)

The typealias will create an ambiguity with qualified lookup yes. Furthermore such typealiases should only be allowed one scope level deeper because otherwise the typealias will shadow the generic type parameter and it would be impossible to reference it.

struct P<A> {} 
extension P { 
  typealias A = Int // not okay

  func foo() {
    typealias A = Int // okay after qualified lookup is allowed
    ...
    _: P<A>.A = ... // will still resolve to `Int` 
    ...
    // we can disambiguate with qualified lookup only if the shorthand syntax is
    // also accepted; then the compiler can infer the generic type and workaround
    // the shadowing in the current scope 
    _: P.A = ... // OKAY; similar to `static func == (lhs: Array, rhs: Array) -> Bool`
  }
}
1 Like
11

Not the compiler, the language version (mode you build with) -swift-version. But it doesn't matter since it's a separate bug relative to your proposal, so we can just make it a redeclaration and hope we don't break the source compat suite.

UDP Apologies, not a redeclaration, an ambiguous type for member lookup in a nominal type context (referring to it from outside a type is yet alright).

12

TBH it's okay if breaks the compatibility suite, because it's something that should have been disallowed from the beginning and can be considered as a bug abuse.

I'll file that issue soon, since it's somehow closely related to the proposal I want to write. (I'll let you know in case you want to add some additional commentary on the JIRA issue.)

2 Likes