Remove traits with unconstrained Time associated types.
#324
Conversation
As discussed in rust-embedded#201 and rust-embedded#177 (comment) , the traits that have an unconstrained `type Time` associated type end up not being usable for HAL-independent drivers in practice, since there is too much variation across HALs of what the actual Time type is. These should be bound to something, probably a `Duration` trait, so that drivers can actually create and use them. Alternatively embedded-hal could have actual `struct Duration` and so. Either way, it's unclear what the final solution would look like. We shouldn't leave these traits in the 1.0 release, since fixing them later will be a breaking change. We should temporarily remove them, and add them back once we have figured this out which won't be a breaking change.
|
r? @eldruin (rust-highfive has picked a reviewer for you, use r? to override) |
|
Uh, this removes a few traits. |
|
I've created this source graph query on the bases of #177 (comment) to see, which crate is implementing these traits and also to give an overview, which Based on the curated drivers list on awesome-embedded-rust and a quick and dirty script, But even smaller queries did not lead to any matches at all. So this might be the wrong way to get an idea, which driver uses these traits. (Or there are just no matches at all) But hopefully this creates a basis for discussion. |
|
thanks for the analysis! there's definitely room for improvement on em, which either way will be a breakage i guess, but, i still feel a little wary of removing all these (also particularly interested in whether this has flow-on impact on RTIC timer definitions?) i'm not sure this achieves all goals, but, what if instead of associated types we elected here to define a really basic timestamp / duration type (maybe something like |
|
I feel like, in previous discussion and PRs it was made clear, that the most important priority Everything, that misses that goal, should not be part of this crate. And, as of now, the traits which will be removed in this PR do miss the goal with the unconstrained The fear of breaking many downstream crates while removing these traits is very real and very reasonable, so this problem should be solved.
Even though this sounds like an interesting idea, I propose we should not go this route. Any discussion about an alternative simple IMHO, more important right now is to solve the breakage issue for downstream HAL implementations and maybe inter-op between HAL impls and RTIC apps. First of, I don't think this is a blocker for this PR in particular, but we should have a solution for that concern before I have a few ideas, but I'm not really particularly happy with anyone of these (maybe someone else can iterate ontop of these ideas):
I'm out of ideas, but maybe there are other solutions as well. |
|
|
|
@burrbull it was designed to work together with We can redesign and add it back later, either as a "Pwm" peripheral with multiple pins/channels, or a standalone "PwmPin" that just allows setting duty % without "caring" about the full peripheral... |
It is not true. |
|
I stand corrected then! I still think it suffers from a similar issue: it has an unconstrained |
There was a problem hiding this comment.
As discussed in yesterday's meeting, let's remove all traits with unconstrained associated types for the 1.0 release and add them back later on piece by piece as we figure out what constraints we can specify on them, which would make them usable for HAL-independent code.
For HALs that implement them, they have the following options:
- Continue offering implementations using the traits from the
embedded-hal0.2.x versions which should reduce the ecosystem fragmentation and keep any dependent code working. - Copy the removed traits into the HALs and keep everything as-is.
- Offer only inherent methods on the structs.
- Remove the implementations.
TODO before merging/releasing this:
- Update changelog
@therealprof agreed yesterday as well.
Opinions @ryankurte ?
|
i'm a little sad to see us dropping rather than replacing em, but, seems reasonable to get us unblocked. would it be useful to point folks to |
There was a problem hiding this comment.
Yeah, we should start some kind of "Get me those traits back" initiative and detail what the types could be :)
Ok, let's merge this as-is and I will update the changelog separately.
For anyone finding this in the future, if you are interested in any of the removed traits, please speak up in the issues we will open about this.
bors r+
354: Remove Qei trait as it has an unconstrained associated type r=ryankurte a=eldruin For now. See #324 for the reasoning. Co-authored-by: Diego Barrios Romero <[email protected]>
|
@eldruin please point to the issues you mentioned. I have several drivers I'd like to publish in the next months that depend on timer traits (especially |
|
Thanks for the reminder @niclashoyer. |
As discussed in #201 and
#177 (comment) ,
the traits that have an unconstrained
type Timeassociated type end upnot being usable for HAL-independent drivers in practice, since there is too
much variation across HALs of what the actual Time type is.
These should be bound to something, probably a
Durationtrait, so thatdrivers can actually create and use them. Alternatively embedded-hal could have
actual
struct Durationand so.Either way, it's unclear what the final solution would look like. We shouldn't leave
these traits in the 1.0 release, since fixing them later will be a breaking change.
We should temporarily remove them, and add them back once we have figured this out
which won't be a breaking change.