@zth Actually, looking at the module itself and its interface, I can see that the function are defined equally in both:
here is @rescript/core/src/Core__Float.resi:
@val
external parseInt: ('a, ~radix: int=?) => float = "parseInt"
And here is @rescript/core/src/Core__Float.res
@val external parseInt: ('a, ~radix: int=?) => float = "parseInt"
From this part of the documentation, if the function type annotation has ~paramName: type=? the function implementation should have ~paramName: option<type> doesn’t it? Not sure how this works with the external keyword.
But besides that, I could see this:
We have a parseIntWithRadix that is deprecated and suggesting the usage of the parseInt with optional arguments, but isn’t this the exactly opposite what rescript recommends on the documentation?
Shouldn’t we “undeprecate” parseIntWithRadix and make parseInt receive only the integer and not an optional radix?
Core__Int.fromString could call Core__Float.parseInt(x) (which is per se a little odd to me, why the Int module would call the Float module to parse an Int value?) or Core__Float.parseIntWithRadix(x, ~radix)