mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-22 06:44:35 +00:00
2c7ce1c453
Allow `~const` on associated type bounds again This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds). Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up. This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`. ```rs #[const_trait] trait Trait { type Assoc: ~const Trait; fn func() -> i32; } const fn function<T: ~const Trait>() -> i32 { T::Assoc::func() } ``` `~const` associated type bounds also work together with `const` bounds: ```rs struct Type<const N: i32>; fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above Type } ``` NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them? For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`). ~~[``@]rustbot`` ping project-const-traits~~ r? project-const-traits |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| messages.ftl | ||