Discuss the possibility of denying `bare_trait_objects` in 2021 edition

Summary

Bare trait objects do not interact well with const generics, as if a user does not surround a const expression with {}, it can be parsed as a trait object (e.g. foo + bar is interpreted as dyn foo + bar), which leads to confusing errors. See, for instance: https://github.com/rust-lang/rust/pull/77502#discussion_r499172677. If we deny bare_trait_objects in the 2021 edition, which is a permitted edition change, we can emit better errors for const generics, a feature we hope to stabilise in the form of min_const_generics in the near future.

bare_trait_objects would continue to work pre-2021 edition. Thus, the better error messages will only be available in the 2021 edition.

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.

[scottmcm]

To me, at least, those don’t seem persuasive enough to dissuade from making dyn strictly required.

• One can presumably just do type MyBoxedDynAny<T> = dyn MyBoxedDynAnyTrait<T>; if you want to expose something as a type instead of a trait.
• That use has always felt somewhat like a hack to me, vs a representation like would be done at runtime like transmute::<{ Neglect { alignment: true, .. } }(...) or something. Or even transmute::<{Neglect::Alignment | Neglect::SomethingElse}>(...) with a const BitOr for whatever that type would be. It’s certainly a fun hack, while const generics are as limited as they currently are, but I’m still not a fan of it.

[Mark-Simulacrum]

Closing in favor of https://github.com/rust-lang/rust/pull/83213, as discussed in today’s planning meeting. That PR has the outcome of various discussions (and is currently in FCP).