You can clone with
No one assigned
I just stumbled over the following behavior while hunting down a bug caused by it:
> fromJSON (Number 260) :: Result Word8
it :: Result Word8
Imho, the conversion above should have failed in order to detect when assumptions w.r.t. the JSON serialization are wrong, as 260 can't be properly represented in a Word8; or put differently, I'd expect the following pseudo law/property to hold:
toJSON <$> fromJSON x == pure x -- iff fromJSON succeeds
For better or worse, this behaviour is consistent with existing practice: conversions to narrower integral types truncate, they don't throw exceptions.
I'm not sure where the right place to handle this kind of error is. Perhaps doing it in aeson makes sense, but then we need to decide how to report a truncation.
I think that the best thing to do, if you want to check truncation, is to write some newtype wrappers that will perform the check in fromIntegral.
@bos, fyi, as I've slowly started to accept that the usual integer types don't model an integer range but rather integers module a range, I'm now thinking about using the safeint types (which do represent an integer-range) and raise parse errors in their fromJSON instances...
Makes sense to me.