You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
Example (live):
Under #2173, the return type of
#1
is not rewritten toi32
, becauseimpl as
doesn't change the interface ofB
, and the return type of#3
is rewritten toi32
, becauseextends
does change the interface ofB
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 thatT.(AInt.T)
would be rewritten.However, that could lead to inconsistent behavior: some references to the associated constant
T
in an instance ofB
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.The text was updated successfully, but these errors were encountered: