[tialaramex]

> 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.

[gpderetta]

So you would have different, say, distinct division operators for each of u8, u16, u32, u64, u128 and their signed variant, for each floating point type, complex numbers (and all their underlying variants), quaternions, etc? You might quickly run out of operator soup.

[tialaramex]

How did you get to this very strange understanding from what I wrote ?

We have two arguably distinct operations so we might want two operators, but you have instead invented a plethora, seeming to understand that somehow the operators ought to depend on the type, which is part of the original mistake.

(5 // 2 == 2) whereas (5 / 2 == 2.5) those are two distinct operations

In many places Rust for example chooses to provide multiple operations but to only grant the most C-like operation an operator, e.g. (-15_i32).div_euclid(2) is -8 that's Euclidean division but (-15_i32) / (2) is -7 as you'd likely expect in C