Why does a generic method inside a trait require trait object to be sized?

Traits and Traits

In Rust, you can use trait to define an interface comprised of:

• associated types,
• associated constants,
• associated functions.

and you can use traits either:

• as compile-time bounds for generic parameters
• as types, behind references or pointers.

However... only some traits can be used directly as types. Those traits that do are labeled Object Safe.

It is now considered unfortunate that a single trait keyword exists to define both full-featured and object-safe traits.

Interlude: How does run-time dispatch work?

When using a trait as a type: &Trait, Box<Trait>, Rc<Trait>, ... the run-time implementation uses a fat pointer composed of:

• the data pointer,
• the virtual pointer.

Method calls are dispatched through the virtual pointer to a virtual table.

For a trait like:

trait A {
    fn one(&self) -> usize;
    fn two(&self, other: usize) -> usize;
}

implemented for type X, the virtual table will look like (<X as A>::one, <X as A>::two).

The run-time dispatch is thus performed by:

• picking the right member of the table,
• calling it with the data pointer and arguments.

This means that <X as A>::two looks like:

fn x_as_a_two(this: *const (), other: usize) -> usize {
    let x = unsafe { this as *const X as &X };
    x.two(other)
}

Why cannot I use any trait as a type? What's Object Safe?

It's a technical limitation.

There are a number of traits capabilities that cannot be implemented for run-time dispatches:

• associated types,
• associated constants,
• associated generic functions,
• associated functions with Self in the signature.
• ... maybe others ....

There are two ways to signal this issue:

• early: refuse to use a trait as a type if it has any of the above,
• late: refuse to use any of the above on a trait as a type.

For now, Rust chooses to signal the issue early on: traits that do not use any of the above features are call Object Safe and can be used as types.

Traits that are not Object Safe cannot be used as types, and an error is immediately triggered.

Now what?

In your case, simply switch from compile-time polymorphism to run-time polymorphism for the method:

pub trait Messenger : Sync + Send {
    fn send_embed(&self, u64, &str, f: &FnOnce(String) -> String)
        -> Option<u64>;
}

There is a little wrinkle: FnOnce requires moving out of the f and it's only borrowed here, so instead you need to use FnMut or Fn. FnMut is next more generic method, so:

pub trait Messenger : Sync + Send {
    fn send_embed(&self, u64, &str, f: &FnMut(String) -> String)
        -> Option<u64>;
}

This makes the Messenger trait Object Safe and therefore allows you to use a &Messenger, Box<Messenger>, ...

Dynamic dispatch (i.e. calling methods through trait objects) works by calling through a vtable, (i.e. using a function pointer), since you don't know at compile time which function it will be.

But if your function is generic, it needs to be compiled differently (monomorphised) for every instance of F which is actually used. Which means you'll have a different copy of send_embed for every different closure type it's called with. Every closure is a different type.

These two models are incompatible: you can't have a function pointer which works with different types.

However, you can change the method to use a trait object as well instead of being compile-time generic:

pub trait Messenger : Sync + Send {
    fn send_embed(&self, u64, &str, f: &Fn(String) -> String)
        -> Option<u64> where Self: Sync + Send;
}

(Playground)

Instead of a different send_embed for every type which can be Fn(String) -> String, it now accepts a trait object reference. (You could also use a Box<Fn()> or similar). You do have to use Fn or FnMut and not FnOnce, since the latter takes self by value, i.e. it's also not object safe (the caller doesn't know what size to pass in as the closure's self parameter).

You can still call send_embed with a closure/lambda function, but it just needs to be by reference, like this:

self.messenger.send_embed(0, "abc", &|x| x);

I've updated the playground to include an example of calling send_embed directly with a referenced closure, as well as the indirect route through a generic wrapper on Bot.