Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zygoloid opened this issue Dec 17, 2022 · 1 comment
Labels
leads question A question for the leads team

Comments

@zygoloid
Copy link
Contributor

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.

@zygoloid zygoloid changed the title should qualified access to a constraint member pick up rewrites from the constraint? should qualified access to a constraint member pick up rewrites from the qualifier? Dec 17, 2022
@github-actions
Copy link

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.

@github-actions github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Mar 17, 2023
@josh11b josh11b added leads question A question for the leads team and removed inactive Issues and PRs which have been inactive for at least 90 days. labels Sep 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
leads question A question for the leads team
Projects
None yet
Development

No branches or pull requests

2 participants