Redesign modules that require generics

[auguwu]

The design for some modules (like charted_search) would want a trait with methods that accept generic types, but generic types aren't object-safe, so what do we do to keep it easy and maintainable?

use charted_search::SearchService;

// some options to use to modify the request body
pub struct Options {}

// a service that extends `SearchService`
pub struct MyService {}

impl SearchService for MyService {
    type Options = Options;

    fn index() { /* do some indexing */ }
    fn search() { /* do some search */}
}

Even though hacks do exist where we would have to use an enum to differentiate without getting the dreaded we cannot turn this object-safe as we would want to use generics for:

• Index Name: Into<String>
• Index Type: serde::DeserializedOwned/serde::Serialize

I'm wondering if there is any way we could do this where we can keep a dyn SearchService without doing more enum hacks and making it harder to maintain multiple objects that implement a trait that require dynamic dispatch.

I was thinking of doing a "hacky vtable" but I'm not too sure if we can do:

struct Vtable {
  do_index: unsafe fn(a: impl Trait<Of, Some, Sorts>) -> /* result */,
}

and calling it since Rust treats fn as a function pointer rather than a type (like Fn, which function pointers do implement!) and only generate what implementation of the Trait<T, U, V> is used, and it is a design chosen by the Rust language, and I think we need to think for now on how to keep this maintainable without dreading hacky solutions.

Using enums and generating an implementation of that is still too hacky for me since it's more code that is only there to patch existing designs by Rust.