You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
What is the purpose of embedded-hal?
What makes a trait a good or poor candidate for inclusion?
What stability / interoperability guarantees should we make / expect?
So, let's get started below~!
cc. @rust-embedded/hal
The text was updated successfully, but these errors were encountered:
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.
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 toembedded-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
The text was updated successfully, but these errors were encountered: