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

Consider splitting PackageUrl type into owned and borrowed variants? #9

Open
alilleybrinker opened this issue May 25, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@alilleybrinker
Copy link

Right now the PackageUrl type unifies owned and borrowed variants with Cow under the hood. While this works, it means that code wanting to work with owned PackageUrls either needs to thread lifetimes through their usage code which are largely irrelevant, or force 'static to ensure only string slices or non-borrowed underlying data are used.

An alternative would be to split between the owned and borrowed variant, with getter methods on the borrowed variant (and accessible to the owned variant via Deref impl), and with ownership conversion traits implemented as appropriate.

This would more closely match the String/str, PathBuf/Path, OsString/OsStr, CString/CStr split seen in other "stringy" types in the Rust standard library.

@althonos
Copy link
Owner

I think actually this crate needs a rewrite in terms of API, and I can see PackageUrl being an owned variant while a new PackageUrlBuilder can be used with owned or borrowed strings in order to build a package URL.

@althonos althonos added the enhancement New feature or request label May 26, 2023
@alilleybrinker
Copy link
Author

Oh that's interesting. Perhaps PackageUrl and PackageUrlRef, with both being able to be built by PackageUrlBuilder based on the use of owned or borrowed types? I'd be happy to talk through that API in more detail if you'd like!

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

No branches or pull requests

2 participants