should qualified access to a constraint member pick up rewrites from the qualifier?

[zygoloid]

trafficstars

Example (live):

interface A {
  let T:! Type;
}
constraint AInt {
  extends A where .T = i32;
}
interface B {
  impl as AInt;
}

// #1. Return type is not rewritten.
fn F(T:! B) -> T.(A.T);

// #2. Rewritten?
fn G(T:! B) -> T.(AInt.T);

interface C {
  extends AInt;
}

// #3. Return type is rewritten.
fn H(T:! C) -> T.T;

// #4. Rewritten?
fn I(T:! C) -> T.(A.T);

Under #2173, the return type of #1 is not rewritten to i32, because impl as doesn't change the interface of B, and the return type of #3 is rewritten to i32, because extends does change the interface of B to include the rewrite.

But what about #2 and #4? The explorer implementation currently uses the name after the . only to identify the associated constant, and looks for rewrites in the type of the name before the ., so #2 is not rewritten and #4 is, but it strikes me that it could also be reasonable to also look for rewrites in the context in which the associated constant was found, allowing us to rewrite #2. It certainly seems reasonable to expect that T.(AInt.T) would be rewritten.

However, that could lead to inconsistent behavior: some references to the associated constant T in an instance of B would be rewritten, and others would not, depending on how the associated constant happens to be named, which seems confusing and error-prone. I think it's probably best to use the explorer behavior here for that reason, but I'm curious what other people think.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. \n\n\n This issue is labeled inactive because the last activity was over 90 days ago.