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.