Update rtree object: impl RTreeObject for Arc and Rc

[QIU1995NONAME]

• I agree to follow the project's code of conduct.
• I added an entry to rstar/CHANGELOG.md if knowledge of this change could be valuable to users.

---

[michaelkirk]

This seems reasonable. Should we include implementations for other smart pointer types (at least Rc)?

[QIU1995NONAME]

Hi, I originally wanted to implement something like this:

impl<P, T> RTreeObject for P
where
    P: Deref<Target = T> + Drop,
    T: RTreeObject + ?Sized,

or

impl<P, T> RTreeObject for P
where
    P: Borrow<T> + Drop,
    T: RTreeObject + ?Sized,

However, it conflicts with the existing implementations.
If I just copy the existing impl<T> RTreeObject for Arc<T> block, it ends up duplicating quite a bit of code.

Do you have any suggestions on how to handle this more cleanly?

Thanks!

[adamreichold]

However, it conflicts with the existing implementations.

What is the conflict? Can the conflicting implementation be subsumed under a more general one?

[QIU1995NONAME]

Right now, the known conflicts include things like:

pub struct CachedEnvelope<T: RTreeObject> 

and

impl<P> RTreeObject for P
where
    P: Point,

These overlap with the more generic impl<P, T> patterns I mentioned earlier.

[michaelkirk]

The Arc/Rc impls look good to me.

re: adding Cargo.lock - personally I'm in favor of checking in Cargo.lock, but it could generate some discussion, so let's put that in a separate commit and PR.

[QIU1995NONAME]

re: adding Cargo.lock - personally I'm in favor of checking in Cargo.lock, but it could generate some discussion, so let's put that in a separate commit and PR.

As you can see, ignoring the Cargo.lock file causes the test case (georust/geo-ci:rust-1.63) to fail.

Should we update the CI test case to handle this, or would it be better to commit the Cargo.lock file first?

Note: This issue has already been resolved in PR #213, where the Cargo.lock file is included.

[michaelkirk]

Can you please update the changelog and remove your changes to .gitignore