Skip to content

Add singular and plural units to from_str impl. #212#214

Merged
iliekturtles merged 2 commits into
iliekturtles:masterfrom
bheisler:master
Oct 22, 2020
Merged

Add singular and plural units to from_str impl. #212#214
iliekturtles merged 2 commits into
iliekturtles:masterfrom
bheisler:master

Conversation

@bheisler

Copy link
Copy Markdown
Contributor

This adds the singular and plural unit strings to the match in from_str, which means that strings containing them can be parsed.

I found that there are a number of quantities in uom which have at least one unit where the singular and plural is the same. There is also pressure, where pounds-per-square-inch is defined in two different ways. Because of this, the match sometimes includes multiple arms with the same string, resulting in a compiler warning. I've ignored this warning just on the generated match.

I've also updated the tests to check that the expected strings can be parsed.

@Aehmlo

Aehmlo commented Oct 21, 2020

Copy link
Copy Markdown
Contributor

Seeing that it's an explicit test case, I gather that e.g. "1 meters" parses. I just want to make sure that this is the desired end result. In my applications, I would expect an attempt to parse such a string to be suggestive of a bug elsewhere. I do suspect that checking this edge case may be nontrivial, though, and we probably don't want to get too far into input validation. I guess it comes down to the concept of a balance between human-friendly, permissive parsing vs. stricter parsing discussed in #212.

@bheisler

Copy link
Copy Markdown
Contributor Author

I think that disallowing "1 meters" would require a strange edge-case in the code for little to no benefit, so I would recommend allowing it. It's up to you though.

Validation rules like that perhaps make more sense to define at the application level.

@iliekturtles iliekturtles left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Thanks for the PR! I'll review in more depth tomorrow. I feel like there should be more test cases but I'm not sure what they could be yet.

Comment thread src/quantity.rs
Comment on lines +515 to 520
match unit.trim() {
$($abbreviation => Ok(Self::new::<super::super::$unit>(value)),)+
$($singular => Ok(Self::new::<super::super::$unit>(value)),)+
$($plural => Ok(Self::new::<super::super::$unit>(value)),)+
_ => Err(UnknownUnit),
}

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

The current code can be simplified:

                        match unit.trim() {
                            $($abbreviation | $singular | $plural => Ok(Self::new::<super::super::$unit>(value)),)+
                            _ => Err(UnknownUnit),
                        }

We could also consider only matching singular when value.is_one() and plural when not. This would require separate matches as written currently in order to fit the match guards. If we do end up going this route then only one macro iteration $(...)+ is needed around all three lines instead of one on each line.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We could also consider only matching singular when value.is_one() and plural when not.

As @bheisler said above, being strict in this sense seems to provide little benefit especially when parsing user input. I would suggest erring on the side of lenience here following the parsing adage "be lenient in what you accept, be strict in what you generate".

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I've updated it to simplify the code, as suggested.

@iliekturtles iliekturtles merged commit 6f5fbbc into iliekturtles:master Oct 22, 2020
@iliekturtles

Copy link
Copy Markdown
Owner

Thanks again for the PR!

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.

4 participants