abi_stable_crates VS rust-default-arguments-benchmark

I've used abi_stable_crates

It's possible, I even made a PR for closures a few months ago. However, for some odd reason the CI failed to build it, and months later I tried to update my PR only to find that master didn't build anymore on my machine.

Integration with /u/azure1992's abi_stable crate for API/ABI mismatch checking (layout_checks feature). Note that CGlue will not work with crates.io version just yet, as a certain patch needs to be published first. But in the meantime, this can be solved by specifying the upstream repo in cargo patch section.

There’s a crate for that: abi_stable

Unfortunately, just before publishing this article I found out, that Rust does not guarante a stable ABI, not even between two separate runs of the compiler with the same rustc version. This measn that plugins might suddenly not be compatible anymore for no obvious reasons. Even though I never experienced any problems during development (neither on windows, linux nor mac), I'd recommend you to just share datastructures with #[repr(C)] attribute or use types from abi_stable_crates. A stable ABI will be shipped with minfac:0.0.2, as datastructures in minfac:0.0.1 don't have the #[repr(C)] attribute yet. A discussion about having a stable Rust ABI can be found in the internals forum. If anybody knows, why compiling with the compiler option -C prefer-dynamic is supported, I'd be interested to know, as I can't see how this problem is solved there.

Here’s abi_stable_crates, enabling Rust API to be exported with a stable ABI

This crate may also be of interest: https://github.com/rodrimati1992/abi_stable_crates/

I've added the builder pattern to my benchmark. The results were that the 3 implementations were indistinguishable when function inlining was allowed. When inlining was not allowed, both the default trait pattern and the builder pattern suffered similar performance penalties (maybe those penalties are actually associated to having a struct as argument?).