Description
What is this
This is a design document for const generics. Any discussions about its content should be on zulip. The conclusions of these discussions should then be edited back into this issue. Please do not post any comments directly in this issue.
Content
We have to decide which types may be used as a const parameter and whether there needs to be explicit opt-in.
Allowing a type to be used as a const parameter type adds additional stability guarantees.
Stability guarantees of const parameter types
These issues stem from the fact that const parameters rely on structural equality (#29).
If a type is used as a const parameter, one must not add a field to that type which does not have structural equality, e.g. raw pointers.
Const parameters also make it far easier to rely on the exact behavior of structural equality, meaning that changing something from structurally equal to merely semantically equal is far more likely to be breaking.
Possible ways forward
We could require const parameter types to only have public fields, meaning that there is no way to break their use for const parameters in a way which isn't already considered a breaking change. This isn't too great as it feels somewhat arbitrary doesn't easily extend to types like NonZeroUsize.
Require types to explicitly opt-in. Most likely by adding an explicit #[derive(StructuralEq)] which is recursively checked for all fields. Depending on the results of #29 we may also use a different name for this, but using a new trait which has to be explicitly added seems like the right step forward.