Hey all,
Based on the discussion around trait implementations, upgrades, and breakage mitigation I think it'd be useful to have a chat about what our goals / objectives / expectations for embedded-hal are and depending how it goes to look to refining and formalising the outcome both for our reference and to communicate to embedded-hal consumers.
Imo this library is one of the most important parts of / opportunities with embedded rust, I think there are likely to be some strong feelings (I know I have some), so let's make a point of remembering that while we may have different experiences and opinions, we're all on the same page here, working towards making the embedded rust experience excellent ^_^
Here's an absolutely non-exhaustive list of talking points to get started:
So, let's get started below~!
cc. @rust-embedded/hal
What is the purpose of embedded-hal?
Provide an interface to easily and generically interface between different hardware components and applications.
What makes a trait a good or poor candidate for inclusion?
A good trait needs to be generic enough to be applicable to a lot of vastly different hardware while being simple enough to allow for easy use. Both overengineered traits as well as vendor specific traits are bad candidates.
What stability / interoperability guarantees should we make / expect?
As soon as there're implementations out there using a trait (as indicated by the proven predicate) it shouldn't be changed anymore. If an incompatible modification is required for reasons which couled/were not foreseen before marking the trait(s) as proven, then a new (set of) trait(s) should be offered as replacement or extension, if possible with compatibility bridge. Breaking existing traits automatically means incompatibility of users relying on that trait in different versions which kills the user experience which, in my opinion, is the single most important aspect of anything we do.
I think we can probably close this for inactivity, thanks for the thoughts!
Most helpful comment
Provide an interface to easily and generically interface between different hardware components and applications.
A good trait needs to be generic enough to be applicable to a lot of vastly different hardware while being simple enough to allow for easy use. Both overengineered traits as well as vendor specific traits are bad candidates.
As soon as there're implementations out there using a trait (as indicated by the
provenpredicate) it shouldn't be changed anymore. If an incompatible modification is required for reasons which couled/were not foreseen before marking the trait(s) as proven, then a new (set of) trait(s) should be offered as replacement or extension, if possible with compatibility bridge. Breaking existing traits automatically means incompatibility of users relying on that trait in different versions which kills the user experience which, in my opinion, is the single most important aspect of anything we do.