An Incoherent Rust

65 points by ettolrach

don't worry, it's even worse in embedded Rust. The most recent crate of the Pi Pico hardware abstraction library uses such old versions of the arm cortex libraries that their traits for things as basic as the clocks and timers are fully incompatible with peripheral connection libraries last updated several years ago.

wrs

At least most or all the embedded libraries are somewhat honest and have 0.x (or 0.0.x) version numbers. But yeah, building on sand isn’t great for getting work done.
vaguelytagged

I think rust is just still too young in embedded. If you really want something durable you're going to need to create it from scratch. Even in higher level programs I often have to bind to a C library to get what I need rather than pull down and off the shelf crate. I do think this gets better with time

dureuill

Yet another issue solved by adding a level of indirection 😉

Very good blog post and proposal. That said, I'm a bit unsure about the incoherent keyword (not the name, semantics) and the justification for why incoherence should be opt-in.

The whole discussion about the fact that Hashmap should move its bounds to the struct makes me feel like incoherent trait are going to be a footgun: something easy to get wrong or to retrofit badly. It also tells me that adding incoherent to a trait is probably a breaking change in a public API, as downstream users could accidentally create "Hashmap issues" by adding impls to the now incoherent trait.

If so that means that we'll still need a serde2 with an incoherent serialize, although at least with overlapping named impl we would be able to define impl LegacySerialize<T> = serde2::Serialize for T where T: serde::Serialize

Bikeshedding asides:

Not a fan of the concept of directly using the impl name as a bound. It looks to me like we'll never really know the difference between trait bounds and impl-name bounds. I'd much rather we'd use a syntax like: Trait with impl-name, so the takes_cloneable example would be instantiated with takes_cloneable::<Clone with Impl1>(MyType(1)); and the associative type example would be <() as Trait with ATrait>::Assoc.
Actually, do we need explicit names at all? We could reuse the path where an impl has been defined as its name. The obvious flaw is when you want to define adjacent overlapping impl, which would'nt be possible in that way. Still it would spare us from coming up with names for abstract things like impls...

austreelis

It also tells me that adding incoherent to a trait is probably a breaking change in a public API, as downstream users could accidentally create "Hashmap issues" by adding impls to the now incoherent trait.

Isn't that what incoherence is ? What I understood the goal of supporting incoherence to be was to allow adding impls, but still somehow error out when the hasmap issues arise (or any other).
- dureuill
  
  That goal doesn't seem like it is met by the proposal, because it additionally requires that the bounds of the types on HashMap are migrated from the impls to the struct to solve the "HashMap problem".
  
  To me this tells us that modifying a trait to make it incoherent is not backward compatible since it allows introducing the hashmap problem