Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: lifetime of geometry referenced by PreparedGeometry (version 1) #175

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vladaburian
Copy link
Contributor

No description provided.

ptr: PtrWrap<*const GEOSPreparedGeometry>,
geom: Option<Geometry>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this field used for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's so that PreparedGeometry can optionally own the related Geometry (and have optionally static lifetime). It either has static lifetime and owns the geometry, or has limited lifetime tied to external Geometry (in which case the geom field is None).

with_context(|ctx| unsafe {
let ptr = GEOSPrepare_r(ctx.as_raw(), g.as_raw());
PreparedGeometry::new_from_raw(ptr, ctx, "new")
})
}

pub fn new_owning(g: Geometry) -> GResult<PreparedGeometry<'static>> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big fan of this but I suppose it's for the case where someone wants to return both a Geometry and a PreparedGeometry right? If so I don't think it's a case that we should allow. There are many ways to handle it and I don't think returning both types from a function is a good Rust use case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's for case when someone wants to be able to move PreparedGeometry freely around, encapsulate in inside some struct etc. I think it's valid case, not something that should be difficult or impossible to do. I have posted some examples in the issue. I don't see the other ways to handle it (or perhaps the answer is to not encapsulate PreparedGeometry anywhere, but that sound very limiting.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants