Our great sponsors
-
gdbstub
An ergonomic, featureful, and easy-to-integrate implementation of the GDB Remote Serial Protocol in Rust (with no-compromises #![no_std] support)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
inlinable-dyn-extension-traits
An exploration into the various ways optional trait methods can be implemented in Rust.
I ran into almost this exact same problem while working on gdbstub, whereby I an API that allowed users to mix/match protocol features however they wanted, while also preventing users from accidentally implementing mutually-exclusive features. Moreover, I wanted to have a "zero cost" way to enable/disable API features without relying on cargo features. The solution I came up with is something I've been calling "Inlineable Dyn Extension Traits", or IDETs.
I don't like how you call it an "abuse" of the Rust trait system, though. It's exactly what I'm trying to avoid, I want to be as idiomatic as possible and not end up with an anti-pattern like inheritance abusing Defer.
I've spent quite a bit of time staring at assembly output and performing in-application testing to make sure that optimizations were being triggered as expected.