Hello everybody, I recently realised something while browsing the core library of Rust. It is about an old and recurrent debate that might have arisen in every programming language creation (or at least every modern language). I'm sorry if this topic have already been debated.
Which arithmetic operations does trait num::Num have? - add, div, mul, rem, sub. And which types implement trait num::Num? - int, uint, (+ fixed size variants) and float (+ fixed size variants). To me this is fundamentally wrong. Because the euclidean division of integer types is a distinct operation from the division of floats. Int family aims at reproducing the arithmetic of ZZ (or NN) which is a ring (or a semi-ring) while Float family tries to reproduce the behavior of RR which is field. So yeah yeah yeah, I know, that's not how C works and Rust tries to remain highly compliant with C language. But what? This way operation div in trait num::Num is very unlikely to be used at all because it is very unlikely to me that anyone would like to have a function where division could be euclidean or natural depending on the type of the inputs. Actually, I find very natural to have two different traits (I don't mind the names, it's just for the example): - num::IntegerNum with functions add, eucDiv, mul, rem, sub - num::GenericNum with functions add, eucDiv, div, mul, rem, sub Note that for floats, euclidean division (as euclidean remainder) is still a meaningfull operation. So num::GenericNum can be a sub-trait of num::IntegerNum. One other important question is: which behavior should be chosen for the two euclidean operations? As I feared, for now Rust just imitates C. My point is: in all the programs I've ever writen, I think I have never used the pair "truncated division + remainder" (which is the only operations C-family languages have) and I've always found myself recoding the pair "floored division + modulo" which makes more sense mathematically. Some of you certainly know this topic provoked a big debate when Guido van Rossum changed python's behavior in favor of the latter option. I personnally think he was absolutely right, even if (of course) it would have been better to think about it from the beginning instead of creating a breaking change for such a primitive operation. I don't mind if Rust also has the first pair of operations for compatibility with C, I just think it would be great if it naturally has both. -- Eddy
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
