Author's Note: This is copied from RFC 2632 by @oli-obk, but changed to match a discussion on zulip (archive) where we settled on something that is better than the original proposal. This is to encourage more discussions around the new syntax and also acts as a scaffold to reopen the RFC with its contents changed to match the new syntax.
Summary
Allow impl const Trait for trait impls where all method impls are checked as const fn.
Introducea new syntax for trait bounds: T: ~const Trait must be satisfied with const
impls when called in a const context. This allows the body of the const fn to call trait methods on
the generic parameters.
Motivation
Without this RFC one can declare const fns with generic parameters that have trait bounds, but one is
not able to call trait methods on the generic parameters, because we can't enforce the trait methods
to be const.
Guide-level explanation
You can mark trait implementations as having only const fn methods.
Instead of adding a const modifier to all methods of a trait impl, the modifier is added to the trait
of the impl block:
struct MyInt(i8);
impl const Add for MyInt {
fn add(self, other: Self) -> Self {
MyInt(self.0 + other.0)
}
}
You cannot implement both const Add and Add for any type, since the const Add
impl is used as a regular impl outside of const contexts. Inside a const context, you can now call
this method, even via its corresponding operator:
const FOO: MyInt = MyInt(42).add(MyInt(33));
const BAR: MyInt = MyInt(42) + MyInt(33);
You can also call methods of generic parameters of a const function when they are bounded with ~const. For example, the ~const Add trait bound can be used to call Add::add or + on the arguments
with that bound.
const fn triple_add<T: ~const Add<Output=T>>(a: T, b: T, c: T) -> T {
a + b + c
}
The obligation is passed to the caller of your triple_add function to supply a type which has a
const Add impl.
To ensure associated types' bounds require impl consts for the type used for the type, one must
also use ~const on the bound:
trait Foo {
type Bar: ~const Add; // means "when in a const impl, requires Bar to have a const Add impl"
}
impl const Foo for A {
type Bar = B; // B must have an `impl const Add for B`
}
If an associated type has no bounds in the trait, there are no restrictions to what types may be used
for it. If the bounds are not annotated with ~const, then it does not require impl consts for those types.
Generic bounds
The above section skimmed over a few topics for brevity. First of all, impl const items can also
have generic parameters and thus bounds on these parameters, and these bounds should also be marked with ~const when you need all bounds to only be substituted with types
that have impl const items for all the bounds. Thus the T in the following impl requires that
when MyType<T> is used in a const context, T needs to have an impl const Add for Foo.
impl<T: ~const Add> const Add for MyType<T> {
/* some code here */
}
const FOO: MyType<u32> = ...;
const BAR: MyType<u32> = FOO + FOO; // only legal because `u32: const Add`
Furthermore, if MyType is used outside a const context, there are no constness requirements on the
bounds for types substituted for T.
Drop
A notable use case of impl const is defining Drop impls.
Since const evaluation has no side effects, there is no simple example that
showcases const Drop in any useful way. Instead we create a Drop impl that
has user visible side effects:
let mut x = 42;
SomeDropType(&mut x);
// x is now 41
struct SomeDropType<'a>(&'mut u32);
impl const Drop for SomeDropType {
fn drop(&mut self) {
*self.0 -= 1;
}
}
You are now allowed to actually let a value of SomeDropType get dropped within a constant
evaluation. This means that
(SomeDropType(&mut 69), 42).1
is now allowed, because we can prove that everything from the creation of the value to the destruction is const evaluable.
const Drop in generic code
To be able to know that a T can be dropped in a const fn, T: ~const Drop will be treated specially. In non-const functions this
would make no difference, but const fn adding such a bound would allow dropping values of type
T inside the const function. Additionally it would forbid calling a const fn with a T: ~const Drop
bound with types that have non-const Drop impls (or have a field that has a non-const Drop impl).
struct Foo;
impl Drop for Foo { fn drop(&mut self) {} }
struct Bar;
impl const Drop for Bar { fn drop(&mut self) {} }
struct Boo;
// cannot call with `T == Foo`, because of missing `const Drop` impl
// `Bar` and `Boo` are ok
const fn foo<T: ~const Drop>(t: T) {}
Note that one cannot implement const Drop for structs with fields with just a regular Drop impl.
While from a language perspective nothing speaks against that, this would be very surprising for
users. Additionally it would make const Drop pretty useless.
struct Foo;
impl Drop for Foo { fn drop(&mut self) {} }
struct Bar(Foo);
impl const Drop for Bar { fn drop(&mut self) {} } // not ok
// cannot call with `T == Foo`, because of missing `const Drop` impl
const fn foo<T: ~const Drop>(t: T) {
// Let t run out of scope and get dropped.
// Would not be ok if `T` is `Bar`,
// because the drop glue would drop `Bar`'s `Foo` field after the `Bar::drop` had been called.
// This function is therefore not accepted by the compiler.
}
Runtime uses don't have const restrictions
impl const blocks are treated as if the constness is a generic parameter
(see also effect systems in the alternatives).
E.g.
impl<T: ~const Add> const Add for Foo<T> {
fn add(self, other: Self) -> Self {
Foo(self.0 + other.0)
}
}
#[derive(Debug)]
struct Bar;
impl Add for Bar {
fn add(self, other: Self) -> Self {
println!("hello from the otter side: {:?}", other);
self
}
}
impl Neg for Bar {
fn neg(self) -> Self {
self
}
}
allows calling Foo(Bar) + Foo(Bar) even though that is most definitely not const,
because Bar only has an impl Add for Bar
and not an impl const Add for Bar. Expressed in some sort of effect system syntax (neither
effect syntax nor effect semantics are proposed by this RFC, the following is just for demonstration
purposes):
impl<c: constness, T: const(c) Add> const(c) Add for Foo<T> {
const(c) fn add(self, other: Self) -> Self {
Foo(self.0 + other.0)
}
}
In this scheme on can see that if the c parameter is set to const, the T parameter requires a
const Add bound, and creates a const Add impl for Foo<T> which then has a const fn add
method. On the other hand, if c is "may or may not be const", we get a regular impl without any
constness anywhere.
For regular impls one can still pass a T which has a const Add impl, but that won't
cause any constness for Foo<T>.
This goes in hand with the current scheme for const functions, which may also be called
at runtime with runtime arguments, but are checked for soundness as if they were called in
a const context. E.g. the following function may be called as
add(Bar, Bar) at runtime.
const fn add<T: ~const Neg, U: ~const Add<T>>(a: T, b: U) -> T {
-a + b
}
Using the same effect syntax from above:
<c: constness> const(c) fn add<T: const(c) Neg, U: const(c) Add<T>>(a: T, b: U) -> T {
-a + b
}
Here the value of c decides both whether the add function is const and whether its parameter
T has a const Add impl. Since both use the same constness variable, T is guaranteed to have
a const Add if add is const.
This feature could have been added in the future in a backwards compatible manner, but without it
the use of const impls is very restricted for the generic types of the standard library due to
backwards compatibility.
Changing an impl to only allow generic types which have a const impl for their bounds would break
situations like the one described above.
const default method bodies
Trait methods can have default bodies for methods that are used if the method is not mentioned
in an impl. This has several uses, most notably
- reducing code repetition between impls that are all the same
- adding new methods is not a breaking change if they also have a default body
In order to keep both advantages in the presence of impl consts, we need a way to declare the
method default body as being const. The exact syntax for doing so is left as an open question to
be decided during the implementation and following final comment period. For now one can add the
placeholder #[default_method_body_is_const] attribute to the method.
trait Foo {
#[default_method_body_is_const]
fn bar() {}
}
While we could use const fn bar() {} as a syntax, that would conflict
with future work ideas like const trait methods or const trait declarations.
Reference-level explanation
The implementation of this RFC is (in contrast to some of its alternatives) mostly
changes around the syntax of the language (allowing const modifiers in a few places)
and ensuring that lowering to HIR and MIR keeps track of that.
The miri engine already fully supports calling methods on generic
bounds, there's just no way of declaring them. Checking methods for constness is already implemented
for inherent methods. The implementation will have to extend those checks to also run on methods
of impl const items.
Precedence
A bound with multiple traits only ever binds the const to the next trait, so ~const Foo + Bar
only means that one has a const Foo impl and a regular Bar impl. If both bounds are supposed to
be ~const, one needs to write ~const Foo + ~const Bar. More complex bounds might need parentheses.
Implementation instructions
(deleted)
Const type theory
(deleted)
Drawbacks
- It is not a fully general design that supports every possible use case, but it covers the most common cases. See also the alternatives.
- It becomes a breaking change to add a new method to a trait, even if that method has a default
impl. One needs to provide a
constdefault impl to not make the change a breaking change. - It becomes a breaking change to add a field (even a private one) that has a
Dropimpl which is notconst Drop(or which has such a field).
Rationale and alternatives
ConstDrop trait to opt into const-droppability
(deleted)
Effect system
A fully powered effect system can allow us to do fine grained constness propagation (or no propagation where undesirable). This is out of scope in the near future and this RFC is forward compatible to have its background impl be an effect system.
Fine grained const annotations
One could annotate methods instead of impls, allowing just marking some method impls
as const fn. This would require some sort of "const bounds" in generic functions that
can be applied to specific methods. E.g. where <T as Add>::add: const or something of
the sort. This design is more complex than the current one and we'd probably want the
current one as sugar anyway.
Require const bounds everywhere
(replaced with ~const bounds)
Infer all the things
We can just throw all this complexity out the door and allow calling any method on generic
parameters without an extra annotation iff that method satisfies const fn. So we'd still
annotate methods in trait impls, but we would not block calling a function on whether the
generic parameters fulfill some sort of constness rules. Instead we'd catch this during
const evaluation.
This is strictly the least restrictive and generic variant, but is a semver hazard as changing a const fn's body to suddenly call a method that it did not before can break users of the function.
Future work
This design is explicitly forward compatible to all future extensions the author could think about. Notable mentions (see also the alternatives section):
- an effect system with a "notconst" effect
- const trait bounds on non-const functions allowing the use of the generic parameter in constant expressions in the body of the function or maybe even for array lenghts in the signature of the function
- fine grained bounds for single methods and their bounds (e.g. stating that a single method is const)
It might also be desirable to make the automatic Fn* impls on function types and pointers const.
This change should probably go in hand with allowing const fn pointers on const functions
that support being called (in contrast to regular function pointers).
Deriving impl const
#[derive(Clone)]
pub struct Foo(Bar);
struct Bar;
impl const Clone for Bar {
fn clone(&self) -> Self { Bar }
}
could theoretically have a scheme inferring Foo's Clone impl to be const. If some time
later the impl const Clone for Bar (a private type) is changed to just impl, Foo's Clone
impl would suddenly stop being const, without any visible change to the API. This should not
be allowed for the same reason as why we're not inferring const on functions: changes to private
things should not affect the constness of public things, because that is not compatible with semver.
One possible solution is to require an explicit const in the derive:
#[derive(const Clone)]
pub struct Foo(Bar);
struct Bar;
impl const Clone for Bar {
fn clone(&self) -> Self { Bar }
}
which would generate a impl const Clone for Foo block which would fail to compile if any of Foo's
fields (so just Bar in this example) are not implementing Clone via impl const. The obligation is
now on the crate author to keep the public API semver compatible, but they can't accidentally fail to
uphold that obligation by changing private things.
RPIT (Return position impl trait)
const fn foo() -> impl Bar { /* code here */ }
does not allow us to call any methods on the result of a call to foo, if we are in a
const context. It seems like a natural extension to this RFC to allow
const fn foo() -> impl const Bar { /* code here */ }
which requires that the function only returns types with impl const Bar blocks.
Specialization
Impl specialization is still unstable. There should be a separate RFC for declaring how
const impl blocks and specialization interact. For now one may not have both default
and const modifiers on impl blocks.
const trait methods
This RFC does not touch trait methods at all, all traits are defined as they would be defined
without const functions existing. A future extension could allow
trait Foo {
const fn a() -> i32;
fn b() -> i32;
}
Where all trait impls must provide a const function for a, allowing
const fn foo<T: Foo>() -> i32 {
T::a()
}
even though T is not bounded by the ~const modifier.
The author of this RFC believes this feature to be unnecessary, since one can get the same effect by splitting the trait into its const and nonconst parts:
trait FooA {
fn a() -> i32;
}
trait FooB {
fn b() -> i32;
}
const fn foo<T: ~const FooA + FooB>() -> i32 {
T::a()
}
Impls of the two traits can then decide constness of either impl at their leasure.
const traits
A further extension could be const trait declarations, which desugar to all methods being const:
const trait V {
fn foo(C) -> D;
fn bar(E) -> F;
}
// ...desugars to...
trait V {
const fn foo(C) -> D;
const fn bar(E) -> F;
}
const function pointers and dyn Trait
See the original RFC for more details.
explicit const bounds
const on the bounds (e.g. T: const Trait) requires an impl const Trait for any types used to
replace T. This allows const trait bounds on any (even non-const) functions, e.g. in
fn foo<T: const Bar>() -> i32 {
const FOO: i32 = T::bar();
FOO
}
Which, once const items and array lengths inside of functions can make use of the generics of
the function, would allow the above function to actually exist.
Unresolved questions
Resolve syntax for making default method bodies const
The syntax for specifying that a trait method's default body is const is left unspecified and uses
the #[default_method_body_is_const] attribute as the placeholder syntax.
Resolve keyword order of impl const Trait
There are two possible ways to write the keywords const and impl:
const impl Trait for Typeimpl const Trait for Type
The RFC favors the latter, as it mirrors the fact that trait bounds can be const. The constness
is not part of the impl block, but of how the trait is treated. This is in contrast to
unsafe impl Trait for Type, where the unsafe is irrelevant to users of the type.
Resolve syntax of ~const
This RFC would introduce another sigil if we decide to use ~const. ?const would not be a good
option as giving the meaning of ~const to ?const makes it inconsistent with the meaning of ?Sized.
Closing Note: There are two fundemantal changes to the original RFC:
-
Semantics Change: Previously,
T: Traitwas inferred to be aconst boundand?constwas the syntax to opt-out the inferred bound. In this RFCT: Traitwill not be changed at all, we add a new modifierT: (whatever) Traitto signify a const bound. (note that it is not strictly a const bound, but a "const-if-const" bound. If the const fn is used in runtime, then those bounds are treated as normal bounds.) -
Syntax Change: We use
~constinstead of?constto signify the "const-if-const"ness. Please comment if you can come up with something better than~const, this is definitely up for bikeshed.