Allow Member Lookup to Find Generic Parameters

[Douglas_Gregor]

@DevAndArtist

Since I had no idea about the correct terminology of this pitch I choose the former title and hoped it will describe the aligned behaviour. I edited the title like you suggested, but I’m not 100% sure it still fits perfectly.

It's possible that I haven't captured your intent well with my suggestion.

@DevAndArtist

I wonder if the qualified lookup can have a few more forms. For instance in the future when SE-0068 is finally implemented it would be great if we can allow this:

class Y<Element> {
  var e1: Element // nothing new
  var e2: Y<Element>.Element // resolves to `Element`
  var e3: Self.Element // resolves to `Element`
}

Yes, I believe this follows from SE-0068 and your proposal.

@DevAndArtist

Is there a technical reason why we don’t do the same with subclasses of generic classes? (Here Self.Element would start to make sense, or in a non-generic subclass you could use the unqualified lookup to access the generic type parameter from the super class.)

class Generic<X> {
  var x: X?
}

class NonGenericSub : Generic<Int> {
  var xx: X? // this is not possible today, nor `Self.X`
}

class GenericSub<X, Y> : Generic<Y> {
  var xx: X? // That is a comletely different `X`
}

All of the above fits well as a consequence of your proposal.

The second version I have in mind is a shorthand form of qualified lookup that can be used to disambiguate certain scenarios like for instance this made up example:

struct FirstDimension<Element> {
  // `FirstDimension.Element` is the shorthand form.
  // In this case we cannot write `FirstDimension<Element>.Element` because we would
  // then refer to the `Element` of the `SecondDimension` generic struct.
  struct SecondDimension<Element> where Element == FirstDimension.Element {
    ...
  }
}

The reference to FirstDimension.Element does work, because FirstDimension.Element is interpreted as FirstElement<Element>.Element (using the outer "Element" generic parameter). Personally, I regret the rule that makes FirstDimension shorthand for FirstDimension<Element>; it causes confusion with type inference, and SE-0068 is a better answer here. Regardless, the example above will work with your proposal.

On "ignoring some generic type parameters when needed":

@DevAndArtist

It may reduce the complexity of the proposal but why shouldn’t we be able to ignore certain generic parameters when needed. The same functionality does already exist for protocols with multiple associated types:

protocol TestProtocol {
associatedtype A
associatedtype B
var a: A { get }
var b: B { get }
}

func test<T>(_ t: T) where T : TestProtocol, T.A == Int {
print(t.a * 10)
}

Sure this is a small example that works better if you do it the other way around, but it was completely made up. There might be better examples that could fit in here if for instance you have a few more generic type parameters but for your algorithm you only care about a smaller set of them.

That works well for protocols because "T: TestProtocol" is a conformance constraint. That's the main concern I have with your original example:

@DevAndArtist

func test<T>(_ t: T) where T : Generic, T.A == Int {
print(t.a * 10)
}

Here, T: Generic isn't a conformance constraint, or a superclass constraint: it's a same-type constraint where the actual type arguments to Generic imply (hidden) type parameters. Personally, I find that to be too magical to reason about, and in the examples I've seen so far don't feel like improvements.

@DevAndArtist

Could you also explain what you mean if generic parameters are API? (I’m clearly not familiar with this way of expression it.)

By API, I mean that they are part of the contract between the designer of the generic type and any user of the generic type. You can't change the name of a generic parameter without breaking client code, because the type parameter names are used by extensions.

Doug