Remove R: Read bounds on structs #88
Labels
Comments
This was referenced Apr 4, 2017
Merged
arnauorriols
pushed a commit
to arnauorriols/streams
that referenced
this issue
Sep 3, 2021
Trait bounds should generally be pushed to the latest moment when they are actually needed. That is, the functions that manipulate the data and that actually require the bound. It is usually avoided (to the reasonable extend) to put trait bounds in the type parameters of data types and trait declarations, as they unleash an unergonomic "trait bound hell" and are usually overly restrictive. Some relevant references: - [API Guidelines] - [discussion API Guidelines] - [flat2 case] - [Haskell Programming Guidelines] In this case, the trait bounds "Sync" and "Send" are already enforced (if necessary) when the async runtime actually schedule the Futures, and it is at this point (if actually enforced by the runtime) that all the types and intermediate functions that manipulate those types are required to enforce these markers; However, if at any point of the rabbit hole a type bound is placed on the data, hell breaks loose and all types that touch the bounded type get contaminated. [Implied bounds RFC] might mitigate the issue, but for the time being, this convention is gold one of those that is "all or nothing", because of the "viral" effect. [API Guidelines]: https://rust-lang.github.io/api-guidelines/future-proofing.html#data-structures-do-not-duplicate-derived-trait-bounds-c-struct-bounds [discussion API Guidelines]: rust-lang/api-guidelines#6 [Haskell Programming Guidelines]: https://wiki.haskell.org/Programming_guidelines#Types [flate2 case]: rust-lang/flate2-rs#88 [Implied bounds RFC]: rust-lang/rust#44491
arnauorriols
pushed a commit
to arnauorriols/streams
that referenced
this issue
Sep 3, 2021
Trait bounds should generally be pushed to the latest moment when they are actually needed. That is, the functions that manipulate the data and that actually require the bound. It is usually avoided (to the reasonable extend) to put trait bounds in the type parameters of data types and trait declarations, as they unleash an unergonomic "trait bound hell" and are usually overly restrictive. Some relevant references: - [API Guidelines] - [discussion API Guidelines] - [flat2 case] - [Haskell Programming Guidelines] In this case, the trait bounds "Sync" and "Send" are already enforced (if necessary) when the async runtime actually schedule the Futures, and it is at this point (if actually enforced by the runtime) that all the types and intermediate functions that manipulate those types are required to enforce these markers; However, if at any point of the rabbit hole a type bound is placed on the data, hell breaks loose and all types that touch the bounded type get contaminated. [Implied bounds RFC] might mitigate the issue, but for the time being, this convention is gold one of those that is "all or nothing", because of the "viral" effect. [API Guidelines]: https://rust-lang.github.io/api-guidelines/future-proofing.html#data-structures-do-not-duplicate-derived-trait-bounds-c-struct-bounds [discussion API Guidelines]: rust-lang/api-guidelines#6 [Haskell Programming Guidelines]: https://wiki.haskell.org/Programming_guidelines#Types [flate2 case]: rust-lang/flate2-rs#88 [Implied bounds RFC]: rust-lang/rust#44491
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
None of the
R: Readbounds are required. This includes the following types:All of these need
R: Readbounds on various impls but not on the structs themselves. Having bounds on the structs is annoying because the bounds transitively infect any structs containing any of these types.The
W: Writebounds in contrast are all required because those types have Drop impls that require the bound. Rust currently requires any bound on a Drop implementation to also be present on the struct.The text was updated successfully, but these errors were encountered: