Integer support #210
Integer support #210
Conversation
src/value.rs
Outdated
| /// assert_eq!(i.get(), 5.0); | ||
| /// assert_eq!(f.get(), 2.0); | ||
| /// ``` | ||
| pub fn get(self) -> f64 { |
There was a problem hiding this comment.
Should we have a deprecated get that is an alias for into_f64 for backwards compatibility?
There was a problem hiding this comment.
I thought your PR is API breaking anyway, isn't it?
There was a problem hiding this comment.
You're right. sorry, since floats are strictly not equal to integers of the same value. Do you think it's worthwhile to try to preserve this equality at all for compatibility or otherwise?
|
@torkleyy would you want to review? I figured you know the value semantics better :) |
|
The rebase is done. Is there anything else needed here from me? |
|
Sorry, this needs to be rebased again. |
|
@kvark No problemo. Should be good now. |
|
@CAD97 looks like GHA isn't configured correctly. It doesn't even run on this PR. |
|
@elrnv thank you! Unfortunately we can't proceed until we get CI looking at this. |
|
Thank you! I think the CI fix need to go separately first. |
|
I thought there was an option to run GHA on forks, but I can't find it anymore. I was just trying to see if this would work... :/ |
|
@kvark I set it up the same way that Travis was, to only run on pushes to master/staging/trying. We can set it up to run on PRs as well, that's just another entry to the |
|
@CAD97 travis was definitely checking other forks PRs |
|
#227 bumps up the CI to always run on any PR or any push. Bors would have (of course) still tested on CI. |
|
Can we rebase and squash please? |
Extend the number value variant to distinguish between signed integers and floats.
Add a doc test for map_to on Number.
Added Number::Integer constructors from:
- u64 since we get these for positive integers from the parser.
- i32 since integers default to i32 in Rust, making the simple integer
construction compile: Number::new(3) -> Number::Integer(3)
|
.... I have no idea why GHA aren't running on this PR now. I can only suggest a |
|
I'll try to close and re-open it. |
|
Doesn't seem to help :/ |
|
Maybe related to: Update - We are continuing to work on a fix for the elevated error rates. |
|
CI has run now, anyway. |
|
bors r+ |
|
Build succeeded: |
Roughly following the discussion from #47 and related issues and PRs, this PR extends the Number type (and so indirectly the Value type) to support integers. I hope I didn't grossly misunderstand the discussion there, but I am keen to make adjustments here to make the project better.
I tried to limit the impact to the API to a single breaking change by extending the already opaqueNumbertype rather than theValueenum which exposes its structure. The breaking change is that thegetmethod inNumberis replaced byas_f64andas_i64for getting the appropriate type.Since
IntegerandFloattypes are distinct, they will not be ordered by value (as explained below). This is a breaking change in itself.To maintain the traits on
Number,Integers are simply ordered beforeFloats. This makes float and integer not comparable in value (e.g.Number::Integer(2)<Number::Float(Float(1.0))) because I didn't see any necessity to do so, but I'm open to suggestions.The tests are adjusted to verify that both integers and floats are working.