Pre-RFC: Revamped const_trait_impl aka RFC 2632

language design
81

Oh, so that is the plan, I see. So conceptually, every single type is parameterized by an additional <C: constness>, and then dyn ~const Trait desugars to dyn const(C) Trait referring to this unnamed parameter. And impl<T: ~const Default> ~const Default for MyType<T> is really syntactic sugar for

impl<C: constness, T: const(C) Default> const(C) Default for MyType<C, T> {}

This is somewhat symmetric with types, I guess, which already have two variants (Trait and const Trait) that can also be seen as a single trait with a C: constness parameter.

I assume this means that &dyn const Trait refers to a trait object that must always implement const Trait, even when called at runtime? Is that useful for anything?

Also this means we better be careful when the same type is interpreted inside and outside the const world... we probably have to ensure that all types be covariant in C, i.e, Type<const> is a subtype of Type<non-const>?

1 Like
82

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.