blockers from lang perspective?

[nikomatsakis]

Hi @asomers ! I'm not sure how best to reach you, so I figured I'd open an issue. I'm curious to talk over what are some of the technical blockers you've encountered in authoring mockall, and what it would take to overcome them. For example, I'd like to make sure mockall can support async fns in traits once they're stabilized, and I'd also like to lift the limitations about lifetime vs generic parameters.

[asomers]

Hi Niko! I'm glad to see your interest. And yes, the language presented several challenges while writing this crate. You're right that lifetimes are the biggest limitations. Mockall can't use non-'static generic arguments as function arguments because the matching functions must be downcast to Any (#217). See also https://internals.rust-lang.org/t/hrtbs-for-unspecified-lifetimes/14868 for a discussion of a new language feature that could solve the problem.

Additionally,

• Specialization would help. For one thing, Mockall needs specialization in order to return default values (https://docs.rs/mockall/latest/mockall/#crate-features). For another, specialization could help to mock a generic trait on a non-generic struct multiple times, like From<i32> for MockFoo {} From<f32> for MockFoo {}. See Mock the same generic trait twice on a concrete struct #342. Specialization also makes it easier to print better error messages for "No matching expectation found". See Print better expectation messages on stable #425 .
• async functions in traits aren't really a problem. After all, Mockall already works with the #[async_trait] crate.
• Another problem is the inability for a proc macro to operate on multiple items. If it could, then #[automock] could be used much more widely, such as to mock structs with multiple trait impls. See https://users.rust-lang.org/t/how-to-pass-multiple-items-to-a-derive-macro/91266 . If this were solved, the Mockall would be much easier to use, since mock! could be eliminated for most cases. Also, attribute tags like #[concretize] could be implemented in a less-hacky way. There have been several other proposals for such attribute tags that I've held off from implementing because there's no good way to do it now.

[asomers]

@nikomatsakis do any of those sound like changes that might be possible for the compiler some day?

[nikomatsakis]

Yes. The changes to Any sound very hard, I'd like to understand that a bit better, but I'll have to read the internals thread you linked.

[nikomatsakis]

I mean all of these seem fairly difficult :) but not outside realm of possibility.