stabilize `dyn Trait` in Rust 2015

[nikomatsakis]

This is a sub-issue of #44662 proposing the Rust 2015 stabilization of dyn Trait.

Status

The decision is made, we just need a stabilization PR!

Details

The new syntactic form dyn <relative-path> is added. It is an error to use dyn <relative-path> if path does not name a trait. The result is a so-called dynamic trait type.

For backwards compatibility, dyn can still be used as an identifier -- in other words, it is a contextual keyword. Note also that dyn :: foo parses as a path dyn::foo and not a use of the dyn keyword. You can however write dyn (::foo) to clarify your meaning.

There is a "allow by default" lint that suggests uses of Trait be rewritten to dyn Trait. Much code in rustc was converted using rustfix in conjunction with this lint. I believe the current plan is to keep this lint as "allow by default" for the time being, but make it as part of the "idiom shift" lints for Rust 2018.

Tests

Here are some tests documenting the current behavior:

• Positive uses of dyn Trait, including a use of dyn (::Path).
• dyn by itself is an identifier
• dyn::foo is a path

Other details

Once this is stable, we should adjust the output from ppaux to use it! (#49277)

[nikomatsakis]

cc @petrochenkov, who implemented, and @Manishearth, who has been working on lint etc

[nikomatsakis]

@rfcbot fcp merge

I propose that we stabilize the Rust 2015 behavior of dyn Trait. Details found in the issue header.

[rfcbot]

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

• @aturon
• @cramertj
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @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.

[nikomatsakis]

(Here is a question to ponder, that does not I think block stabilization: for Rust 2018, is it working making dyn a true keyword? If we opt towards crate::foo paths, as I currently prefer, then I am leaning towards "no", since the only weird behavior is around dyn :: foo, and ::foo paths are likely deprecated, so there is then only one reasonable interpretation of such a path. This allows for a gentler transition into Rust 2018.)

[Manishearth]

we opt towards crate::foo paths, as I currently prefer, then I am leaning towards "no", since the only weird behavior is around dyn :: foo, and ::foo paths are likely deprecated, so there is then only one reasonable interpretation of such a path. This allows for a gentler transition into Rust 2018.

This isn't consistent -- crate::foo is an idiom and not a reqirement; however making dyn::foo parse differently is a breaking change; we can't rely on an idiom change to make a breakage "non breaking".

Though it seems like you're suggesting that we could scope the epoch breakage so that dyn stays a contextual keyword, but now dyn::foo parses as dyn Trait -- i.e. instead of breaking all dyn idents we only break it in this one case. That could work, I think.

I do think that contextual keywords should eventually become true keywords and we're well poised to just make it a keyword with the epoch, so idk.

[nikomatsakis]

@Manishearth

however making dyn::foo parse differently is a breaking change;

I am proposing not making it parse differently. It currently parses as a path dyn::foo, and I am claiming that that is the only sensible interpretation in Rust 2018, since ::foo would not be a path on its own (well, it's a deprecated form of path). Though we might want to lint against it.

Though it seems like you're suggesting that we could scope the epoch breakage so that dyn stays a contextual keyword, but now dyn::foo parses as dyn Trait -- i.e. instead of breaking all dyn idents we only break it in this one case. That could work, I think.

As I wrote above, I am proposing that dyn::foo continues to parse as a path, not as a usage of dyn Trait (though perhaps it would be linted against).

I do think that contextual keywords should eventually become true keywords and we're well poised to just make it a keyword with the epoch, so idk.

This is an interesting policy question. Some cases, like catch, really must change. But other cases, like union and -- I think -- dyn, don't necessarily have to. So should we change them to keywords in Rust 2018? I feel divided. I sort of like the idea of 'cleaning up' and being consistent, but I also sort of like the idea of 'make it a lint error and maybe make it a hard error in the next epoch'.

[nikomatsakis]

I noticed something: in our error messages, we don't use dyn (of course). Once it's stable, we should fix that! (Filed #49277)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔