Type `aof_core::memory::MemoryRef` is unusable as it's aliased to ill-formed type `Arc<dyn Memory>` as `Memory` is dyn incompatible

[fmease]

Hello there 👋, I'm a member of the Rust compiler team.

Type alias aof_core::memory::MemoryRef is unusable since using / referencing it anywhere¹ will result in an error as trait Memory isn't dyn compatible (object safe) because it has method retrieve which has generic parameters.

Due to a bug in the Rust compiler or in the Rust language itself, it's currently allowed to specify certain kinds of ill-formed types on the RHS of type alias definitions (CC rust-lang/rust#44075) like in this case where dyn-compatibility is not enforced.

Now, I'm gauging the impact of rejecting such type aliases at their definition site. See PR rust-lang/rust#161358. Thanks to crater I found out that your project would break if we went through with that change (see the crater report) as it would start failing with:

error[E0038]: the trait `Memory` is not dyn compatible
   --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/aof-core-0.4.0-beta/src/memory.rs:171:1
    |
171 | pub type MemoryRef = Arc<dyn Memory>;
    | ^^^^^^^^^^^^^^^^^^ `Memory` is not dyn compatible
    |
note: for a trait to be dyn compatible it needs to allow building a vtable
      for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
   --> /opt/rustwide/cargo-home/registry/src/index.crates.io-1949cf8c6b5b557f/aof-core-0.4.0-beta/src/memory.rs:53:14
    |
 48 | pub trait Memory: Send + Sync {
    |           ------ this trait is not dyn compatible...
...
 53 |     async fn retrieve<T: serde::de::DeserializeOwned>(&self, key: &str) -> AofResult<Option<T>>;
    |              ^^^^^^^^ ...because method `retrieve` has generic type parameters
    = help: consider moving `retrieve` to another trait

Usually, rustc devs would send downstream patches in such cases but in this case I'm not sure how you'd like to proceed: Do you want to remove the faulty type alias MemoryRef or do you want to split the trait Memory in two? Hence me opening an issue instead.

Footnotes

1. Except in other type aliases, of course, which still isn't very useful. ↩