You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you write, say, a CSV or JSON parser, you may want to be able to know about the data type. E.g., in some systems "1.0" and "1" are to be treated differently. It is a niche use case, one where you need to determine the type dynamically, but it is not unreasonnable. Note that you would like the integer value (if it is an integer value) to be returned as an integer type so that you parse integers that would not fit in a floating-point type.
Closing this for now as it's outside of this crate's functionality.
(As a workaround for your use case - you could always check if there's a ., e or E in the source byte string, it should be very fast compared to the time spent actually parsing the float)
Activity
aldanor commentedon Jan 31, 2021
Why, what's the use case? You don't, this information is not exported by the parser as it's not very useful.
lemire commentedon Jan 31, 2021
If you write, say, a CSV or JSON parser, you may want to be able to know about the data type. E.g., in some systems "1.0" and "1" are to be treated differently. It is a niche use case, one where you need to determine the type dynamically, but it is not unreasonnable. Note that you would like the integer value (if it is an integer value) to be returned as an integer type so that you parse integers that would not fit in a floating-point type.
aldanor commentedon Feb 4, 2021
Closing this for now as it's outside of this crate's functionality.
(As a workaround for your use case - you could always check if there's a
.
,e
orE
in the source byte string, it should be very fast compared to the time spent actually parsing the float)lemire commentedon Feb 4, 2021
It seems likely that one could build a derived crate which implements this functionality.