Ah, folly of untyped systems. Tbh this behaviour makes sense given the rules implemented within the language. Anything passed to parseInt is casted to string and then parsed.

Is it shitty behaviour - yes. Does it make sense in given the language implementation - yes.

[–] frezik@midwest.social 1 points 2 minutes ago* (last edited 1 minute ago)

When handling things that are serialized over the wire, you have to do it this way. Yes, you can use typed serialization formats, but in a string-based serializer, there's nothing stopping the other system from sending "0.0000005" on a field that should be an int. If you don't validate that it's an int, you would just pass that value to your equivalent of parseInt().

If you do validate that it's an int, then it still didn't matter if the language has static typing or not. You're doing that at runtime or you're not.

In Rust, doing "0.00005".to_string().parse::<i32>().unwrap() causes a panic on the unwrap() from an invalid digit. However, that's runtime. It's not something the type system can handle statically. The real benefit here, I think, is that it at least forced you to consider that the invalid input could have unexpected results. This is a pretty good reason to be careful about putting unwrap() on everything. The compiler isn't going to save you here.

[–] LarsIsCool@lemmy.world 1 points 1 hour ago

With this reasoning, would you say everything that a computer does makes sense, because it always follows the implementation? Or am I missing something?