4 ms·

Like auto type conversions. Instead of barfing when assigning a Float to an Int, just auto round? Or but then if assigning a string to a float, then barf. Doe

Like auto type conversions. Instead of barfing when assigning a Float to an Int, just auto round? Or but then if assigning a string to a float, then barf. Does this get 80%? I think anything beyond the simple cases, static enforcement is better, or you could be just getting garbage.

recursivedoubts 3y ago
no, i don't think that's where the type system implementation complexity usually explodes, in fact that's a more complicated type system than requiring explicit type conversions (which I am usually in favor of, except in cases of toString)
junon 3y ago
Auto round is rarely the operation you want.
- FrustratedMonky 3y ago
  Guess that is what I am asking. The original post was highlighting it is easier using non-strict types. Like Python. So I was asking, what would that look like, you still loose data, have problems. At least with static checking, the compiler will catch it and then you can add explicate casting.
JohnFen 3y ago
> Instead of barfing when assigning a Float to an Int, just auto round? Rounding involves a loss of data. If an operation would result in data loss, that operation should not be automatic. It should only be possible by the dev intentionally choosing it.
- throwawaymaths 3y ago
  Technically float + float can result in data loss.
  - JohnFen 3y ago
    True, but that's a case where you're doing it on purpose by choosing to do floating point math, where that's standard behavior. That's a bit different than data loss resulting from an assignment operation, where data loss is not standard behavior.
Someone 3y ago
> Instead of barfing when assigning a Float to an Int, just auto round? Because you can’t really round many floats to Int. A float can be larger than 10^38. If you ‘round’ that to a 64-bit signed integer, you have to return something that’s smaller than 10^19. For doubles, it’s even worse. They can be larger than 10^308. I think that indicates that “just auto round” isn’t an option. The option “if a reasonable conversion exists, make it, otherwise bail out” IMO is a lot worse than having a way to try that conversion and somehow indicate to the programmer when it failed.
FrustratedMonky 3y ago
Guess that is what I am asking. The original post was highlighting it is easier using non-strict types. Like Python. So I was asking, what would that look like, you still loose data, have problems. At least with static checking, the compiler will catch it and then you can add explicate casting.

recursivedoubts 3y ago

no, i don't think that's where the type system implementation complexity usually explodes, in fact that's a more complicated type system than requiring explicit type conversions (which I am usually in favor of, except in cases of toString)

junon 3y ago

Auto round is rarely the operation you want.

FrustratedMonky 3y ago
Guess that is what I am asking. The original post was highlighting it is easier using non-strict types. Like Python. So I was asking, what would that look like, you still loose data, have problems. At least with static checking, the compiler will catch it and then you can add explicate casting.

JohnFen 3y ago

> Instead of barfing when assigning a Float to an Int, just auto round? Rounding involves a loss of data. If an operation would result in data loss, that operation should not be automatic. It should only be possible by the dev intentionally choosing it.

throwawaymaths 3y ago
Technically float + float can result in data loss.
- JohnFen 3y ago
  True, but that's a case where you're doing it on purpose by choosing to do floating point math, where that's standard behavior. That's a bit different than data loss resulting from an assignment operation, where data loss is not standard behavior.

Someone 3y ago

> Instead of barfing when assigning a Float to an Int, just auto round? Because you can’t really round many floats to Int. A float can be larger than 10^38. If you ‘round’ that to a 64-bit signed integer, you have to return something that’s smaller than 10^19. For doubles, it’s even worse. They can be larger than 10^308. I think that indicates that “just auto round” isn’t an option. The option “if a reasonable conversion exists, make it, otherwise bail out” IMO is a lot worse than having a way to try that conversion and somehow indicate to the programmer when it failed.

FrustratedMonky 3y ago

Guess that is what I am asking. The original post was highlighting it is easier using non-strict types. Like Python. So I was asking, what would that look like, you still loose data, have problems. At least with static checking, the compiler will catch it and then you can add explicate casting.