Tracking issue for RFC 2300, "`Self` in type definitions"

[Centril]

This is a tracking issue for the RFC "Self in type definitions" (rust-lang/rfcs#2300).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• This syntax creates ambiguity if we ever permit types to be declared directly within impls (for example, as the value for an associated type). Do we ever want to support that, and if so, how should we resolve the ambiguity? A possible, interpretation and way to solve the ambiguity consistently is discussed in the rationale.

[csmoe]

I have tried to solve this, but the dfficulty of this is beyond my current rust-experience so I'd appreciate any mentorship.

[Centril]

re-cc @rust-lang/compiler - could we get some mentoring instructions perhaps per @csmoe's request?

[alexreg]

Currently working on this...

[alexreg]

You can tick off "implemented" now. :-)

[Centril]

@rfcbot merge

Stabilization report & proposal

Feature name: #![feature(self_in_typedefs)]
Version target: 1.32 (2019-01-18)

Originally accepted in rust-lang/rfcs#2300, I propose that we stabilize self_in_typedefs.
This has been in nightly since 2018-08-19 which is ~12 weeks ago.

The proposed change is not a blocker for anyone but it is a nice quality of life feature in some cases.
See the motivation of the RFC for reasons why we would want to do this.

What is being stabilized

Relevant artefacts:

• Implementation
• Unstable book
• Feature gate
• Main tests

The changes are:

1. Self becomes a legal type in struct, enum, and union type definitions and refers to the type being defined. Self is permitted both in fields and in where clauses; For example:

enum List<T>
where
    // In where clauses, both on the side of types being constrained and on the bounds side.
    Self: PartialOrd<Self>
{
    Nil,
    Cons(T, Box<Self>) // In fields. The usual rules re. infinite types apply.
}

What is not being stabilized

Mentions of Self in trait, andtype aliases, and existential types are not being stabilized here.

Divergences from RFC

None

Unresolved questions

There is currently one unresolved question, it reads as:

This syntax creates ambiguity if we ever permit types to be declared directly within impls (for example, as the value for an associated type). Do we ever want to support that, and if so, how should we resolve the ambiguity? A possible, interpretation and way to solve the ambiguity consistently is discussed in the rationale.

At this point I believe that the discussion in the RFC is sufficient and that there is no problem should we ever want to pursue the extension aforementioned.

Thus, I suggest that we resolve the question as a footnote that may have some value in the future but does not impact us now.

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.