Why does returning `Self` in trait work, but returning `Option<Self>` requires `Sized`?
There are two sets of checks happening here, which is why the difference appears confusing.
Each type in the function signature is checked for validity.
Option
inherently requiresT: Sized
. A return type that doesn't requireSized
is fine:trait Works { fn foo() -> Box<Self>; }
The existing answer covers this well.
Any function with a body also checks that all of the parameters are
Sized
. Trait functions without a body do not have this check applied.Why is this useful? Allowing unsized types to be used in trait methods is a key part of allowing by-value trait objects, a very useful feature. For example,
FnOnce
does not require thatSelf
beSized
:pub trait FnOnce<Args> { type Output; extern "rust-call" fn call_once(self, args: Args) -> Self::Output; }
fn call_it(f: Box<dyn FnOnce() -> i32>) -> i32 { f() } fn main() { println!("{}", call_it(Box::new(|| 42))); }
A big thanks to pnkfelix and nikomatsakis for answering my questions on this topic.
It's in the error message:
= note: required by `std::option::Option`
Option
requires the type to be Sized
because it allocates on the stack. All type parameters to a concrete type definition are bound to Sized
by default. Some types choose to opt out with a ?Sized
bound but Option
does not.
Why doesn't the first trait definition already trigger that error?
I think this is a conscious design decision, due to history, future-proofing and ergonomics.
First of all, Self
is not assumed to be Sized
in a trait definition because people are going to forget to write where Self: ?Sized
, and those traits would be less useful. Letting traits be as flexible as possible by default is a sensible design philosophy; push errors to impls or make developers explicitly add constraints where they are needed.
With that in mind, imagine that trait definitions did not permit unsized types to be returned by a method. Every trait method that returns Self
would have to also specify where Self: Sized
. Apart from being a lot of visual noise, this would be bad for future language development: if unsized types are allowed to be returned in the future (e.g. to be used with placement-new), then all of these existing traits would be overly constrained.