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
Currently, we expose multiple type parameters on NetworkBehaviourAction despite all of them being able to be inferred from the corresponding NetworkBehaviour type. However, we do also expose individual mapping functions for the in-event etc.
We could consolidate all those type parameters into one but that would require us to put a bound onto the struct definition. Trait bounds should ideally always only be applied to functionality (i.e. impl blocks). Applying them to struct or enum definition easily creeps through into layers where you don't actually want them.
My suggestion would be to remove all trait bounds from NetworkBehaviourAction and expose the types as they are. For the common case where the types are unmapped, we can expose a type alias that infers all of these types from a type that implements NetworkBehaviour.
Motivation
Current Implementation
Are you planning to do it yourself in a pull request?
Yes.
The text was updated successfully, but these errors were encountered:
Previously, we applied a lifetime onto the entire `RecordStore` to workaround Rust not having GATs. With Rust 1.65.0 we now have GATs so we can remove this workaround.
Related #3240. Without this change, we would have to specify HRTB in various places.
Description
Currently, we expose multiple type parameters on
NetworkBehaviourAction
despite all of them being able to be inferred from the correspondingNetworkBehaviour
type. However, we do also expose individual mapping functions for the in-event etc.We could consolidate all those type parameters into one but that would require us to put a bound onto the struct definition. Trait bounds should ideally always only be applied to functionality (i.e. impl blocks). Applying them to struct or enum definition easily creeps through into layers where you don't actually want them.
My suggestion would be to remove all trait bounds from
NetworkBehaviourAction
and expose the types as they are. For the common case where the types are unmapped, we can expose a type alias that infers all of these types from a type that implementsNetworkBehaviour
.Motivation
Current Implementation
Are you planning to do it yourself in a pull request?
Yes.
The text was updated successfully, but these errors were encountered: