I don't understand the point of both replies... my point was that integer based division is preferred in all languages and the floating point must be somehow "forced" that one operand is float.
The post I was replying to mentions that this sort of problem does not exist in "better languages" but my point was that it does.
The problem here is that the code assigns an integer (result of division) to a float which is implicit "upgrade" in languages like C and C++ and required to be explicit in newer languages like Golang and Rust.
My point, which I seem to have failed to make, is that careless programmers would (and do!) make a silly thing like:
v := float64(operand1 / operand2)
just to satisfy the compiler error.
A common mistake for junior programmers but unforgivable (for some interpretations of unforgivable :) ) one for a senior.
> integer based division is preferred in all languages
What does this even mean?
First of all, several languages have distinct "integer divison" and "floating point division" operators, so there's no sense in which integer is "preferred" in those languages, they're unrelated operations.
Even allowing for your ignorance of such languages many modern languages do not have untyped constants, they're an attractive nuisance. If you don't have untyped constants then even if you're relying on implicit typing for constants (which I also don't like) you trip a mistake in the original expression anyway which is now unalike.
This mistake only occurs in a language with all of:
1. A single division operator despite two distinct operations
2. Untyped constants
3. "Promotion" so that type mismatches just do something unexpected and compile anyway.
prerok|1 year ago
The post I was replying to mentions that this sort of problem does not exist in "better languages" but my point was that it does.
The problem here is that the code assigns an integer (result of division) to a float which is implicit "upgrade" in languages like C and C++ and required to be explicit in newer languages like Golang and Rust.
My point, which I seem to have failed to make, is that careless programmers would (and do!) make a silly thing like:
v := float64(operand1 / operand2)
just to satisfy the compiler error.
A common mistake for junior programmers but unforgivable (for some interpretations of unforgivable :) ) one for a senior.
tialaramex|1 year ago
What does this even mean?
First of all, several languages have distinct "integer divison" and "floating point division" operators, so there's no sense in which integer is "preferred" in those languages, they're unrelated operations.
Even allowing for your ignorance of such languages many modern languages do not have untyped constants, they're an attractive nuisance. If you don't have untyped constants then even if you're relying on implicit typing for constants (which I also don't like) you trip a mistake in the original expression anyway which is now unalike.
This mistake only occurs in a language with all of:
1. A single division operator despite two distinct operations
2. Untyped constants
3. "Promotion" so that type mismatches just do something unexpected and compile anyway.
jshier|1 year ago