-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
need name shadowing rules for Self
#3714
Comments
Another option is that an I am not excited about option 3, since I think |
We have some examples in explorer's prelude that would be broken by impl String as EqWith(Self) { As the type here gets more complicated, we might feel more pressure to make something like this work. @chandlerc observed that we use impl String as EqWith(.Self) { ... }
// Note that this already works -- `.Self` is in scope after `where`.
impl String as AddWith(String) where .Result = .Self { ... }
// And this already works.
let T:! EqWith(.Self) = String; It might be a bit strange that we can use
One other thing we might want to consider: should |
FWIW, I like this last idea (including saying As for where all this would apply -- whenever we are constraining a type? That seems to cover the The only part I struggle with is the spelling itself of |
Per carbon-language#3714, some of the details here are not yet settled. In particular, we might want `Self` to come into scope at the start of the definition, not at the `as` keyword. However, this change allows us to accept the uncontroversial examples.
This comment was marked as spam.
This comment was marked as spam.
Should this be a question for leads @zygoloid ? And do we have an answer? Do we need a proposal? |
Yes, I think we have enough analysis here that we can reasonably make this a leads question and answer it. I think the resolution we've converged on is:
Previously we've said that if there's more than one |
I think we need a proposal to explore the details, but we can probably answer the broad questions as above. |
This is probably one of the details to work out in a proposal, but freely shadowing seems both logical and reasonable, but potentially confusing. Specifically, I'm imagining a case like: |
Would it be reasonable to say that |
Where do we get two Oh, are you specifically suggesting that within a particular branch of a |
I was just mistaken. |
Given
... does
Self
inside theimpl
refer toA
, toi32
, or is it invalid to use it due to ambiguity? Same question applies forSelf
on the right-hand side of theas
. Explorer treatsSelf
here as beingA
-- animpl
only introduces aSelf
if there's not already aSelf
in scope.The same question arises for nested classes:
class A { class B { // ... Self ... } }
I think I would expect that
Self
isB
withinclass B
, rather than namingA
or being ambiguous. Especially given that a lookup forSelf
within the body ofB
should presumably behave the same way ifB
is defined out of line:class A { class B; } class A.B { // ... Self ... }
... and it would be very surprising if
Self
here didn't work.Presumably
interface
s can be nested withinclass
es, where the same question would arise:Is
Self
now the type implementing the interface, or is itA
? I think in this case it must be the type implementing the interface, because there would otherwise be no way to name that type.Some options to consider:
class
,interface
, orimpl
declaration always introducesSelf
, as the class type or implementing type.Self
refers to the innermost such declaration.class
orinterface
always introducesSelf
. Animpl
only introducesSelf
if there's noSelf
in scope.impl
doesn't introduceSelf
ever.The text was updated successfully, but these errors were encountered: