Pre-RFC: Revamped const_trait_impl aka RFC 2632 (original) (raw)

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 Addimpl 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 aconst 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 typeT inside the const function. Additionally it would forbid calling a const fn with a T: ~const Dropbound 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 Barand 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 aconst Add bound, and creates a const Add impl for Foo<T> which then has a const fn addmethod. 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 asadd(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 parameterT 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

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 + Baronly 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

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):

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 Cloneimpl 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 defaultand 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:

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 tounsafe 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: