Remove RTreeObject trait bound on struct def. via default generic param. - #247
Open
mikwielgus wants to merge 1 commit into
Open
mikwielgus wants to merge 1 commit into
mikwielgus wants to merge 1 commit into
Conversation
…aram.
Bounds on struct definitions, unlike bounds on functions, are usually
unidiomatic in Rust, and it is usually possible to rewrite the code
so that there are only bounds on functions, and nothing on the type
definition itself. If you care about this, it becomes a contagious
problem to rely on `rstar` in your own generic code, because the `T:
RTreeObject` bound propagates upward.
For example,
```
pub struct Layout<T: RTreeObject> {
objects: Vec<T>,
rtree: RTree<T>,
}
```
must have an `RTreeObject` bound on `T`, even though this code's authors
may not want to expose that to their downstream in their code's public
interface.
(the above of course also applies to enums)
See also this Stack Overflow answer:
https://stackoverflow.com/a/66369912
This PR is a proposal to solve this problem by adding an additional
generic parameter `E` to `rstar`'s types that defaults to
`RTreeObject::Envelope`.
mikwielgus
force-pushed
the
remove-bounds-from-struct
branch
from
September 8, 2026 22:26
a97085a to
45eedda
Compare
fogti
suggested changes
Sep 10, 2026
| serde(bound( | ||
| serialize = "T: Serialize, T::Envelope: Serialize", | ||
| deserialize = "T: Deserialize<'de>, T::Envelope: Deserialize<'de>" | ||
| serialize = "T: Serialize, E: Serialize", |
Contributor
There was a problem hiding this comment.
These special bounds can afaik be removed now, as they are equal to the default
| serde(bound( | ||
| serialize = "T: Serialize, T::Envelope: Serialize", | ||
| deserialize = "T: Deserialize<'de>, T::Envelope: Deserialize<'de>" | ||
| serialize = "T: Serialize, E: Serialize", |
2 tasks
| )) | ||
| )] | ||
| pub struct RTree<T, Params = DefaultParams> | ||
| pub struct RTree<T, Params = DefaultParams, E = <T as RTreeObject>::Envelope> |
Member
There was a problem hiding this comment.
Adding a generic type parameter that is not really a free parameter does not make sense IMHO. It suggests that RTree<T, Params, E> means something even if E = <T as RTreeObject>::Envelope does not hold and this just is not the case. Or at least it is definitely not something I would want to support in the public API of this crate.
Meaning this might be a reasonable trick for the implementation details of a crate, but not for its public API.
TechPizzaDev
pushed a commit
to TechPizzaDev/rstar-rs
that referenced
this pull request
Sep 12, 2026
- [X] I agree to follow the project's [code of conduct](https://github.com/georust/geo/blob/master/CODE_OF_CONDUCT.md). - [ ] I added an entry to `rstar/CHANGELOG.md` if knowledge of this change could be valuable to users. --- This has the same motivation as georust#247 (but is orthogonal/independent to that), particularly that these trait bounds "bleed" into downstream usage, e.g. in https://docs.rs/polygon_unionfind and https://github.com/mikwielgus/anyangle .
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bounds on struct definitions, unlike bounds on functions, are usually unidiomatic in Rust, and it is usually possible to rewrite the code so that there are only bounds on functions, and nothing on the type definition itself. If you care about this, it becomes a contagious problem to rely on
rstarin your own generic code, because theT: RTreeObjectbound propagates upward.For example,
must have an
RTreeObjectbound onT, even though this code's authors may not want to expose that to their downstream in their code's public interface.(the above of course also applies to enums)
See also this Stack Overflow answer: https://stackoverflow.com/a/66369912
This PR is a proposal to solve this problem by adding an additional generic parameter
Etorstar's types that defaults toRTreeObject::Envelope.rstar/CHANGELOG.mdif knowledge of this change could be valuable to users.