Allow Member Lookup to Find Generic Parameters

As I understand it, the basic premise of this pitch is that generic parameters should be visible to qualified name lookup, i.e., you can refer to them after the name of a generic type:

struct X<Element> {
  var e1: Element   // okay, and has always been okay. this is "unqualified" lookup
  var e2: X<Int>.Element  // start allowing this; it's a "qualified" lookup (X<Int> is the qualifier) and it'll resolve to Int
}

typealias XD = X<Double>
typealias MyDouble = XD.Element // start allowing this qualified lookup; it'll resolve to Double

I think this is a good improvement to Swift. @jrose brought this up recently and mentioned that we should start allowing it. The only reason we didn't allow it was pre-historical: we made the decision not to allow qualified name lookup to find generic parameters before we were certain that generic parameter names would be API. The fact that all extensions use the same names means that generic parameter names are certainly API.

This suggests a shadowing rule, which basically says you can't redefine Element in a way that makes the generic parameter Element impossible to name. This sounds great to me.

I'm not so keen on this one, partly because it's not about the central point of your proposal--which is a change to name lookup---but is instead using "T : Generic" as a shorthand for introducing generic parameters. I think we should continue to write such a signature as:

func test<B>(_ t: Generic<Int, B>) { }

Both because I find it clearer (at least in the cases I've thought of) and because it makes the overall proposal a smaller change.

One suggestion for messaging: "Align Generic Type Parameters to Associated Types", to me, sounds really big and disruptive. I think titling your proposal/pitch something like "Allow Member Lookup to Find Generic Parameters" would be clearer and less scary.

Doug

5 Likes