warning: very complex type used. Consider factoring parts into type definitions
But if I try to fix that, with
type ChannelCombo = (Sender<(I,P)>, Receiver<(I,P)>);
the compiler tells me:
Error[E0658]: inherent associated types are unstable
--> src/assets/priority_channel.rs:30:5
|
30 | type ChannelCombo = (Sender<(I,P)>, Receiver<(I,P)>);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information
In that issue, from 2013, someone was trying to do what I did here - name a complex type in a generic. That feature isn't in stable yet.
Am I doing this wrong, or is that check in Clippy premature?
as your function header. Potentially more even more usefully, depending on convention and how it's intended to be used, you could even use a named type:
let ChanPair { snd, rcv } = PriorityChannel::init(false);
The complex type lint is ime the most likely "tunable threshold" lint to hit. Certain projects that use a lot of generics (think nalgebra, diesel) naturally have a higher tolerance for complex types.
Given that (Sender<T>, Receiver<T>) is a common idiom, established by std and used by popular ecosystem crates, this example is right on the line, and I think I'd opt to allow the clippy lint in this case, to match reader expectation (who expect to see (Sender<_>, Receiver<_>) in documentation, not e.g. SndRcv<_>, even though the latter removes the potential of the types not matching).