Comments (9)
Yeah, I do kind of think this sort of thing is in scope. I've certainly wanted functions like this in the past as well.
Adding these sorts of routines for integers seems pretty reasonable, but this does open the door for wanting analogous parsing routines for floating point. That is definitely not a road I want to go down. It looks like the lexical project is already meeting this need anyway: https://docs.rs/lexical-core/0.7.4/lexical_core/
So I'd probably want to draw a line in the sand here: integer parsing APIs are okay, but not floats.
from bstr.
This feels like a good "first issue" to me. In particular, routines could be added that are implemented by first converting the input to a &str
and then reusing std's integer parsing. This isn't optimal, but we can always optimize it later.
For anyone who wants to work on this, it would probably be good to start by posting an API proposal in this issue. The API is probably the hardest part of this issue to be honest. For example, do we want a new sub-module with a bunch of concrete functions for each integer? Do we want to define a trait that we implement for all of the integer APIs? I kind of lean towards the latter.
from bstr.
API Proposal: impl FromBStrRadix for {integer}
Rationale
Currently, we call e.g. i32::from_str_radix(src, radix)
.
By analogy, it seems correct to call i32::from_bstr_radix(src, radix)
.
Defining a new trait with that function and then implementing it for the integers makes that work (at the small cost of importing the trait).
It seems reasonable to name the trait after the function.
Implementation
I'm not quite ready to make a PR but I do have a fork up:
alexjago@3487786
What's in it: a new file src/from_bstr_radix.rs
with the trait, impl and tests; plus two lines of changes to src/lib.rs
to use the module and export the trait.
There are a couple of slight differences to the stdlib function.
- Obviously, it takes
src: &BStr
rather thansrc: &str
. Question: should this be anAsRef<[u8]>
instead? radix
is the output type rather than alwaysu32
(easily changeable if desired).- The error type is slightly different. The stdlib returns
Err(ParseIntError {kind: IntErrorKind})
but sincekind
is private and there's no constructor, I just returnErr(IntErrorKind::{variant})
directly. IMHO this is actually more useful.
edit to add: well, IntErrorKind
would be more useful if it didn't require 1.55. Without it, might as well just wrap the std
integer parsing.
from bstr.
@alexjago Thanks! Nice work. Some responses:
- It should definitely take
AsRef<[u8]>
, not&BStr
.&[u8]
is what all of the APIs inbstr
are defined on. - I'm not sure why
radix
would be tied to the output type?u32
feels right to me here. - The error type should definitely not be just a bare
IntErrorKind
. We'll want to define our ownParseIntError
. We can expose thekind
through a method, just like std does.
The "bstr" in the FromBStrRadix
name bugs me a bit, particularly since we're not taking a BStr
but a &[u8]
. Probably a better name is FromBytesRadix::from_bytes_radix
. I don't love it, but I like it better than FromBStrRadix
.
Feel free to submit a PR and we can work through the actual code itself.
from bstr.
Requiring Rust 1.55 is fine. I'm going to bump the MSRV of bstr
up higher. See the 1.0 issue.
from bstr.
There's another API question which occurred to me around panicking and allocating.
The stdlib function (and therefore this one, for now) has an assert
on the radix value... which includes the erroneous value in the error message.
That's an allocation, right? I don't think any other part of the functionality really needs to allocate.
So it's probably fixable with some clever #[cfg]
work (non-alloc
could just... not have a message).
But it also might be an option to redesign the API so that out-of-range radices are a recoverable error, presumably with an additional variant of IntErrorKind
. Obviously if we do that then we can't just re-export the stdlib enum.
from bstr.
You're saying an assert is an alloc? No, it isn't.
Let's stick with how std does things I think wherever we can. The radix is almost always going to be a static input determined by the programmer, so it seems sensible to panic for invalid radix values.
from bstr.
Good to know that asserts don't alloc. (I got this misunderstanding because the format!
macro returns String, but I suppose the underlying machinery just writes to some buffer...)
And yes, I agree that sticking to how std does things makes life more straightforward for everyone.
from bstr.
Well, the assert might alloc when the assert fails. Sure. But that's okay.
from bstr.
Related Issues (20)
- Character-oriented slicing and length APIs HOT 2
- Consider using `once_cell` instead of `lazy_static` HOT 3
- Ensure crate abides by the Unicode Data Files and Software License HOT 4
- bstr pulls in serde when `serde` feature is not specified HOT 6
- bstr-bench Cargo.lock out of sync
- Can the MSRV be lowered to 1.57 (or lower)? HOT 3
- Clarify None case in bstr::decode_utf8 HOT 1
- Feature request: `impl Deserialize for Box<BStr>`
- bstr 1.3.0 with `impl AsRef<BStr> for BStr` breaks some folks downstream HOT 1
- candidate versions found which didn't match: 0.2.17, 0.2.16, 0.2.15, ... HOT 5
- Possible panic safety issues in insert_str HOT 2
- Complementary ByteSlice functions addition - find_not_byte / rfind_not_byte HOT 1
- Use clippy in CI? HOT 2
- Intradoc links are broken when building with no default features HOT 3
- re-enable miri tests
- Accept array of str for split_str HOT 1
- remove `Borrow<BStr> for String` impls (and similar) in a semver compatible release HOT 9
- Add unescape_ascii fn HOT 4
- Display implementation doesn't respect Formatter options
- `bstr::Split` should implement clone. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bstr.