Introduce Size::from_str

[au-phiware]

Thanks for this repo!

I took a stab at the from_str method, I'd appreciate some feedback as I am new to rust.

[mqudsi]

@au-phiware I owe you an incredible apology. You put in all this work to add a pretty big feature to this crate but it's been three years (almost to the day) without a word of feedback!

I cannot remember what happened but I either saw and dismissed the notification that a pull request was opened or missed it altogether. I haven't really had need to touch this crate in all these years as it was working fine for my purposes and your pull request languished.

I just saw this again a few days ago when I resumed work on the size crate to add support for mathematical operations on size types. I will see if I can clean up the merge conflicts and test your code; if all goes well, I can issue a new release with this awesome feature included!

[au-phiware]

No worries, life happens! I vaguely remember writing this PR. I don't remember what all those magic numbers are, my guess would be that Lexer is generated.

[mqudsi]

Yeah, I think src/parser.rs was supposed to be .gitignored as its generated in build.rs. No worries.

[ekisu]

Is there any chance this PR could be revived? This would be a very useful feature

[mqudsi]

In all honesty, this PR has languished because adding a dependency for this does not sit right with me.

[ekisu]

I see, thanks for clarifying

[mqudsi]

It's 5 years later, but I've just added this in #11 without any additional dependencies.

Thank you all (esp. @au-phiware) for your contributions and patience.

[au-phiware]

Well done @mqudsi! Open source can be like that sometimes. Your solution looks simpler by far, but I would still argue that rflex is easier to follow, assuming you can overlook all the boilerplate... but it's 100% your call.

I would like to note that I also catered for exponential notation, e.g. 1.2e-2eb... but I don't remember if I wrote any tests, so that's on me 😅

[mqudsi]

@au-phiware I think you had the more correct solution and the one I'd prefer to maintain, but I couldn't shake the feeling that adding a dependency for this feature wasn't the right approach. I really appreciate your motivating the development of this feature, though!

I would like to note that I also catered for exponential notation, e.g. 1.2e-2eb... but I don't remember if I wrote any tests, so that's on me

I'll share a secret with you: I did the same, and just verified that the following works — but I wasn't sure I wanted to commit to supporting that notation always and forever, so left it out of the docs (and tests):

use size::{Size, EB};

fn main() {
    let text = "1.2e-2 eb";
    let size = Size::from_str(text);
    assert_eq!(Ok(Size::from_bytes(1.2E-2 * EB as f64)), size);
}

(The exact input you provided (with no spaces at all) won't actually parse w/ the current code because in the case of no spaces I split at the first non-numeric/non-dot character to separate between scalar and unit. I guess I can change that to search for the last numeric value and split after there, instead?)

[mqudsi]

index 9d1c9e5..94e41bf 100644
--- a/src/from_str.rs
+++ b/src/from_str.rs
@@ -70,10 +70,11 @@ impl FromStr for Size {
         let (number_str, unit) = match s.split_once(' ') {
             None => {
                 // Possibly in the format 2mib (no separating space)
-                // Try to split at the first non-numeric value.
-                match s.find(|c: char| !c.is_ascii_digit() && c != '.') {
+                // Try to split after the last digit in the input. This supports the (unadvertised)
+                // ability to parse scientific notation w/o spaces between scalar and unit.
+                match s.rfind(|c: char| !c.is_ascii_alphabetic()).map(|i| i +1) {
                     None => (s, ""), // just a number, no unit
-                    Some(idx) => s.split_at(dbg!(idx)),
+                    Some(idx) => s.split_at(idx),
                 }
             }
             Some((num, unit)) => (num, unit),