Name lookup failure #2

[Dave Abrahams]

public trait A { type D }

type X<T: A, D1 where D1 == T.D> {} // error: type 'T' has no member 'D'

[Dimi Racordon]

This issue is related to #1111, as it is blocked by the same problem.

We have to redesign the way generic environments are built because the fact that T has a member D can only be discovered after we have already concluded that T conforms to D. That is not trivial because the generic clause can look like this:

<T, D1 where D1 == T.D, T: A>

I think that the only way to properly cover all cases is to solve a constraint system to compute equivalence classes and build the conformance relation described by the environment. That is not trivial either because we can't rely on standard name resolution while evaluating the type expressions of the environment, as resolving T.D that way would require the environment introducing T to have been built already.

[Dave Abrahams]

the fact that T has a member D can only be discovered after we have already concluded that T conforms to D.

To A you mean.

That is not trivial because the generic clause can look like this:

<T, D1 where D1 == T.D, T: A>

That's only marginally less trivial than the actual example AFAICT. T: A is a ground truth of the system. You evaluate all the where clauses after all the top level conformance assertions.

There may be cases that require a more sophisticated approach but it seems to me you could enable a very large amount of standard library development by temporarily using a fairly simple-minded checker. Whether it's worth the effort to temporarily implement something insufficiently general for our long-term goals, I can't say, but what we currently have is in that category so one possibility is “we did it once—why not again?” A lot of the technical debt in Swift came from using that approach as though it was going to be enough in the long run, which is clearly a bad idea… but, maybe just this once? ;-)

I think that the only way to properly cover all cases is to solve a constraint system to compute equivalence classes and build the conformance relation described by the environment. That is not trivial either because we can't rely on standard name resolution while evaluating the type expressions of the environment, as resolving T.D that way would require the environment introducing T to have been built already.

I don't follow completely but it sounds like that's an assertion based on how name resolution is currently implemented, which—whether it's the right approach or not—I don't understand yet, so I can't comment.