-
Notifications
You must be signed in to change notification settings - Fork 309
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
utilize reserved http-core
crate for primitives
#514
Comments
How does splitting this crate up help? What parts of |
A crate with just primitives could reach v1.0 much more quickly, providing confidence to its users. Also would allow less frequent breaking changes for these types in the face a desire to use newer rustc features (think const panic in HeaderName::from_static) causing raised MSRVs and, therefore, a semver-incompatible release.
Basically the opinionated parts. For example, parts of The parts of |
The fnv crate is tiny. If anyone were motivated, we could very easily just inline it, it's less than 10 lines.
Is it really not possible to do sufficient optimizations with It could be interesting if we could provide Besides that, I think the |
My examples of why we chose to roll our own types don't really illustrate the point of this issue in particular.
If you look at the definition of "primitive" from a lang perspective, then they are building blocks for larger structures, right? Using that, we can say:
|
If you don't think you'll use it, would you consider transferring ownership of the |
Some amount of no_std support could be incrementally added using this reserved crate. See #551. |
Proposal
I noticed you've reserved the
http-core
crate.Would there be interest in moving some of the primitives from
http
down to it?I'm thinking:
Method
Version
StatusCode
Uri
HeaderName
HeaderValue
Motivation
These are the types we use and re-export from
http
in Actix Web.The text was updated successfully, but these errors were encountered: