# Clarify rules around `Self` and `.Self` [Pull request](https://github.com/carbon-language/carbon-lang/pull/2107) ## Table of contents - [Abstract](#abstract) - [Problem](#problem) - [Background](#background) - [Proposal](#proposal) - [Details](#details) - [Rationale](#rationale) - [Alternatives considered](#alternatives-considered) - [`Self` not a keyword](#self-not-a-keyword) - [Make `Self` a member of all types](#make-self-a-member-of-all-types) - [`where` operator could be associative](#where-operator-could-be-associative) ## Abstract A number of smaller changes grouped together in one proposal: - Make `Self` a keyword. - Clarify that `Self` refers to the current type in a base class and in impl declarations. - Clarify when `.Self` is legal, and what type it has. - Also specify that `where` is not an associative operator. ## Problem There were a number of gaps found in the design when @zygoloid went to implement these features in [the explorer codebase](https://github.com/carbon-language/carbon-lang/tree/76c68153a2cf5b35249be3e9b8097238f3dc1ee1/explorer), for example [#1311: Basic support for `.Self` within `:!` bindings and `where` expressions](https://github.com/carbon-language/carbon-lang/pull/1311). ## Background `Self` was introduced for interfaces and implementations in [#524: Generics overview](https://github.com/carbon-language/carbon-lang/pull/524) and [#553: Generics details part 1](https://github.com/carbon-language/carbon-lang/pull/553). `Self` was introduced for class types and methods in [#494: Method syntax](https://github.com/carbon-language/carbon-lang/issues/494) and [#722: Nominal classes and methods](https://github.com/carbon-language/carbon-lang/pull/722). Constraints using `where` and `.Self` were introduced in [#818: Constraints for generics (generics details 3)](https://github.com/carbon-language/carbon-lang/pull/818). The use of `where` to set associated types was introduced in [#1013: Generics: Set associated constants using `where` constraints](https://github.com/carbon-language/carbon-lang/pull/1013). The type of `.Self` and where it would be introduced grammatically was discussed [#generics channel on Discord on 2022-06-07](https://discord.com/channels/655572317891461132/708431657849585705/1013904969335836732). ## Proposal This proposal implements a number of changes and clarifications about the use of `Self` and `.Self` with generics: - `Self` is now a keyword, and may not be used as an identifier even in contexts where `Self` has no meaning. If `Self` is used in a C++ API, Carbon will use the same mechanism for interop as other Carbon keywords. - Clarify that `Self` always refers to the current type, even for virtual functions implemented in a derived class, not the type implementing the method. - `Self` in an `impl` declaration may be used after the `as` to refer to the type being implemented. This could be the type named before `as` when specified, otherwise it is the enclosing type. - Clarify that `.Self` is legal after `:!` and `where`, as long as it only refers to a single type variable. - Specify the type of `.Self` as `Type` after `:!`, or `MyConstraint` after `MyConstraint where`. In addition, this proposal specifies that `where` is not an associative operator. ## Details `Self` was added as a keyword to [`docs/design/lexical_conventions/words.md`](/docs/design/lexical_conventions/words.md). The other rules were added to [`docs/design/classes.md`](/docs/design/classes.md) and [`docs/design/generics/details.md`](/docs/design/generics/details.md). ## Rationale This proposal fills in gaps with an aim to make things consistent and simplify by having fewer rules where possible. For example, the rule saying that it is an error if `.Self` could mean two different things is consistent with other name lookup rules, such as those from [#989: Member access expressions](https://github.com/carbon-language/carbon-lang/pull/989) and [#2070: Always `==` not `=` in `where` clauses](https://github.com/carbon-language/carbon-lang/pull/2070). Simplicity benefits Carbon's [language tools and ecosystem](/docs/project/goals.md#language-tools-and-ecosystem) and consistency leads to [code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write). ## Alternatives considered ### `Self` not a keyword An alternative considered was forbidding identifiers to be equal to `Self`. The big concern with that approach is that we would need some other way to interoperate with C++ code, particularly classes, that had a `Self` member. If we were adding `Self` to the language later as part of evolution, we would make it a keyword. That would allow us to use the same evolution strategy as other keywords -- we would automatically update the code to change existing uses of `Self` to the raw identifier syntax. Note that at this time [no raw identifier syntax has been approved](https://github.com/carbon-language/carbon-lang/pull/93), but Rust uses a `r#` prefix. If Carbon used the same syntax, existing uses of `Self` would be changed to `r#Self`, and so `r#Self` should still be a legal identifier. ### Make `Self` a member of all types We considered making `Self` a member of all types. From this uses of `Self` and `.Self` would follow naturally. It would have other consequences as well: - `T.Self == T` for all types `T`. - `x.Self`, where `x` is a non-type value with type `T`, would be `T`. This is because under the normal member-access rules, since `Self` is not a member of `x`, it would look in `T` and find `T.Self`. This raised the question of whether `Self` is a member of type-of-types like `Type`. That would seem to introduce an ambiguity for `i32.Self`. Furthermore, using `x.Self` to get the type of `x` seemed tricky, it would be better to have something that used the word "type" to do that. Since [`Self` is a keyword](#self-not-a-keyword), we don't need to make it follow the normal member-access rules. So we instead only define what it means in places where we have a use case. This was discussed [on 2022-08-29 in the #typesystem channel in Discord](https://discord.com/channels/655572317891461132/708431657849585705/1013904969335836732). ### `where` operator could be associative We considered making the `where` operator associative, since an expression like ``` Interface1 where .AssocType1 is Interface2 where .AssocType2 == i32 ``` would more usefully be interpreted as: ``` Interface1 where .AssocType1 is (Interface2 where .AssocType2 == i32) ``` than the alternative. However, this is expected to be a rare case and so it seemed much friendlier to humans to require parentheses or a separate named constraint declaration. This way they can easily visually disambiguate how it is interpreted without having to remember a rule that won't commonly be relevant. This was discussed in [the #syntax channel on Discord on 2022-05-27](https://discord.com/channels/655572317891461132/709488742942900284/979869282903130153) and [the weekly sync meeting on 2022-06-01](https://docs.google.com/document/d/1dwS2sJ8tsN3LwxqmZSv9OvqutYhP71dK9Dmr1IXQFTs/edit?resourcekey=0-NxBWgL9h05yD2GOR3wUisg#heading=h.qarzfirrcrgf).