• Feature Name: const_default
• Start Date: 2017-10-17
• RFC PR: (leave this empty)
• Rust Issue: (leave this empty)

Summary

1. Adds the trait ConstDefault to libcore defined as:

pub trait ConstDefault: Default { const DEFAULT: Self; }

2. Adds impls for all types which are Default and where the returned value in default can be const. This includes impls for tuples where all factors are ConstDefault.

3. Enables deriving of ConstDefault for structs iff all fields are also ConstDefault. When Default and ConstDefault are derived together, fn default() is derived as = Self::DEFAULT.

Motivation

The Default trait gives a lot of expressive power to the developer. However, Default makes no compile-time guarantees about the cheapness of using default for a particular type. It can be useful to statically ensure that any default value of a type does not have large unforseen runtime costs.

With a default const value for a type, the developer can be more certain (large stack allocated arrays may still be costly) that constructing the default value is cheap.

An additional motivation is having a way of getting a default constant value when dealing with const fn as well as const generics. For such constexpr + generics to work well, more traits may however be required in the future.

Guide-level explanation

The trait

The following trait:

pub trait ConstDefault: Default {
    const DEFAULT: Self;
}

is added to core::default and re-exported in std::default.

This trait should be directly used if:

• you want to be sure that the default value does not depend on the runtime.
• you want to use the default value in a const fn.

You may also, at your leisure, continue using Default for type T which will yield <T as ConstDefault>::DEFAULT. This is especially true if you are a newcomer to the language as const may be considered an advanced topic.

impls for standard library

Then, impls are added to the types that exist in the standard library which are Default and for which the default value can be const.

For the numeric types, with usize as an example, the impls like the following are added:

impl ConstDefault for usize {
    const DEFAULT: Self = 0;
}

Another example is for (), which less useful, but nonetheless informative:

impl ConstDefault for () {
    const DEFAULT: Self = ();
}

Another, more interesting, case is for Option<T>:

impl ConstDefault for Option<T> {
    const DEFAULT: Self = None;
}

Equally interesting is the case for tuples:

impl<T0, T1> ConstDefault for (T0, T1)
where
    T0: ConstDefault,
    T1: ConstDefault,
{
    const DEFAULT: Self = (T0::DEFAULT, T1::DEFAULT);
}

impl<T0, T1, T2> ConstDefault for (T0, T1, T2)
where
    T0: ConstDefault,
    T1: ConstDefault,
    T2: ConstDefault,
{
    const DEFAULT: Self = (T0::DEFAULT, T1::DEFAULT, T2::DEFAULT);
}

// and so on..

For arrays, impls like the following can be added:

impl<T: ConstDefault> ConstDefault for [T; 2] {
    const DEFAULT: Self = [T::DEFAULT, T::DEFAULT];
}

Deriving

Just as you can #[derive(Default)], so will you be able to #[derive(ConstDefault)] iff all of the type's fields implement ConstDefault. When derived, the type will use <Field as ConstDefault>::DEFAULT where Field is each field's type.

Notably also, since ConstDefault implies Default, it is a logic error on the part of the programmer for Self::default() != Self::DEFAULT, wherefore the compiler, when seeing Default and ConstDefault being derived together will emit:

impl Default for DerivedForType {
    fn default() -> Self { Self::DEFAULT }
}

Assuming a struct with type parameters like struct Foo<A>(A);, the compiler derives:

impl<A: Default> Default for Foo<A> {
    default fn default() -> Self { Foo(A::default()) }
}

impl<A: ConstDefault> Default for Foo<A> {
    fn default() -> Self { Self::DEFAULT }
}

impl<A: ConstDefault> ConstDefault for Foo<A> {
    const DEFAULT: Self = Foo(A::DEFAULT);
}

Reference-level explanation

The trait

The following is added to core::default (libcore) as well as std::default (stdlib, reexported):

pub trait ConstDefault: Default {
    const DEFAULT: Self;
}

impls for standard library

Impls are added for all types which are Default and where the returned value in <T as Default>::default() can be const.

Many of these Default impls are generated by macros. Such macros are changed to generate ConstDefault impls as well as a manually encoded "blanket" impl instead.

An example of how such a changed macro might look like is:

macro_rules! blanket_impl {
    ($type: ty) => {
        impl Default for $type {
            fn default() -> Self { Self::DEFAULT }
        }
    };
}

macro_rules! impl_cd_zero {
    ($($type: ty),+) => {
        $(
            blanket_impl!($type);
            impl ConstDefault for $type {
                const DEFAULT: Self = 0;
            }
        )+
    };
}

impl_cd_zero!(u8, u16, u32, u64, u128, usize, i8, i16, i32, i64, i128, isize);

These macros are internal to the standard library which is free to achieve equivalent results by other means.

Impls are also generated by macro for tuples and arrays. If implemented const generics and const repeat expressions can be used to implement the trait for arrays of arbitrary size, otherwise, impls can be generated by macro for arrays up to a reasonable size.

Deriving

The mechanism and rules used for deriving Default are reused for ConstDefault. They are however altered to produce a const item in the trait instead of a function, and instead of a trait function call, the following is used for a factor Field of a product type (tuples structs, normal structs - including unit structs): <Field as ConstDefault>::DEFAULT.

The compiler also handles deriving ConstDefault in conjunction with Default specially by emitting an impl Default that uses Self::DEFAULT. The compiler is however not obliged to do this, since Self::default() != Self::DEFAULT must always be upheld by the programmer. To not uphold this is a logic error. Special-casing might however have some compile-time performance benefits.

In relation to "Default Fields"

The currently postponed RFC 1806, which deals with struct default field values, allows the user to assign default values from const expressions to fields when defining a struct as in the following example:

struct Foo {
    a: &'static str,
    b: bool = true,
    c: i32,
}

That RFC argues that an alternative to the const requirement is to allow the use of Default::default() instead of just const expressions. However, since Default may incur non-trival runtime costs which are un-predictable, this is not the main recommendation of the RFC. As <T as ConstDefault>::DEFAULT is const, this RFC is fully compatible with that RFC.

RFC 1806 further mandates that when deriving Default, supplied field defaults are used instead of the field type's Default impl. If RFC 1806 is added to this language, for the sake of consistency the same logic should also apply to ConstDefault.

Drawbacks

As always, adding this comes with the cost incurred of adding a trait and in particular all the impls that come with it in the standard library.

Rationale and alternatives

This design may in fact not be optimal. A more optimal solution may be to add a const modifier on the bound of a trait which "magically" causes all fns in it to be considered const fn if possible. This bound may look like: T: const Default. If there are any such implemented trait fns for a given type which can not also be considered const fn, then the bound will be considered not fulfilled for the given type under impl.

The T: const Default approach may be considered heavy handed. In this case it may be considered a bludgeon while the following approach is a metaphorical scalpel: <T as Trait>::method: ConstFn. With this bound, the compiler is told that fn method of Trait for T may be considered a const fn.

While the design offered by this RFC is not optimal compared to the two latter, it is implementable today and is not blocked by: a) adding const fn to traits, b) adding a const modifier to bounds. Such a proposal, while useful, is only realizable far into the future. In the case of the last alternative, Rust must be able to encode bounds for trait fns as well as adding marker trait which constrains the fns to be const. This is most likely even more futuristic.

This RFC advocates that the more optimal alteratives are sufficiently far into the future that the best course of action is to add ConstDefault now and then deprecate it when and if any of the more optimal alternatives are added.

The ConstDefault proposed by this RFC was also independently discussed and derived in the now closed RFC 1520 as what could be achieved with generic consts. The trait was not the actual suggestion of the RFC but rather discussed in passing. However, the fact that the same identical trait was developed independently gives greater confidence in its design.

Unresolved questions

None, as of yet.