Local Default Bounds to assist Forget and other ?Trait.

[Ddystopia]

This RFC proposes a mechanism for crates to define default bounds on generics. By specifying these defaults at the crate level we can reduce the need for verbose and repetitive ?Trait annotations while maintaining backward compatibility and enabling future language evolution.

It is targeted at supporting migrations from default being Trait to ?Trait, where Trait represents some assumption that is present everywhere but is not really exercised a lot, such as Forget, size = stride etc. Features like DynSized, as well as extern types, are out of the scope of this RFC, because it does not fit into this category. DynSized is not retracting mostly unexercised assumptions in order to make it ?DynSized the default.

Primary use case is Forget marker trait.

Rendered

Pre-RFC thread

[Aloso]

Another drawback is that (similar to #[no_std] support and the MSRV) it is yet another thing for library authors to consider: Do I want to support ?Forget types?

• If not, I can just ignore it and won't have any problems. But some users might not be able to use my library.
• If I relax the bound by default, I might get compiler errors which I have to fix, causing churn and slowing down development. And once ?Forget bounds are part of the public API, making them !Forget again is a breaking change.

One situation where it could cause friction is when dependencies do not support ?Forget:

#![default_trait_bounds(?Forget)]

fn frobnicate(x: impl ToString) {
    other_crate::frobnicate(x); // error: `Forget` bound not satisfied
}

That said, I like this proposal and think that the benefits outweigh the drawbacks. Thank you!

[zetanumbers]

It has been discussed multiple times, but if I recall correctly every time the conclusion seems to have been, no we likely don't want a new default bound.
The problem with adding a new default bound is that any type which doesn't implement this trait is pretty much useless unless everyone relaxes the bound when possible. This comes at a huge cost.

#t-lang > The destruction guarantee and linear types formulation @ 💬

I have found this RFC to lack a good justification for breaking Rust language ergonomics in this way.

[tmandry]

I suspect solving the "default" problem is not sufficient. We also need a way to switch modes within a module, which an effect-like system may be better suited for.

This might imply something like a modifier syntax: P: ?Forget Deref, meaning "P implements the ?Forget version of Deref". I would expect an implementation to represent this concept internally, even if we never surfaced it in the language, and would like an RFC to present this as the mental model for what happens when a trait bound "captures" the default bounds in scope. Or if that isn't the right mental model, what is?

[Ddystopia]

@tmandry I'm not sure about the motivation. Can you please explain why do we need a way to switch modes within a module? This RFC is not 100% ultra-generic solution, but more like an attempt to give a specific solution to the specific problem. Do you suggest it will allow better backwards compatibility?