Thanks Graydon for the detailed reply to a newbie suggestion. It looks like I'm a little too late, this ship has already sailed. You're right that it's a topic reasonable people can disagree on. Adding Lint warnings seems like a poor workaround, but maybe the reduced confusion from C developers will outweigh the bugs caused. Or maybe all right-thinking people will agree to use the F-division function calls, and "/" and "%" will be unknown to Rust developers :-)
I just looked over the Numeric traits bikeshed and pull 5990, and have a few comments. ( https://github.com/mozilla/rust/wiki/Bikeshed-Numeric-Traits and https://github.com/mozilla/rust/pull/5990 ) The floating point "quot" operator is now misnamed. It returns "D/d", which is a floating point divide, not a quotient. (src/libcore/num/f32.rs line 323) I would suggest having floating point "quot" and "rem" return proper quotient and remainder (i.e. "D.quot(d)" has the same value for int and float, if the input/result is representable). Then the floating-point "/" operator needs to be mapped to a something other than "quot" (maybe "div_float"?). The "%" operator can be removed on floating point numbers. When a floating-point remainder is needed, you would have to call rem() explicitly. The numeric traits do not appear to require a "%" operator (which is probably a good thing, because it is hard to define for complex numbers). Finally some code review comments (possible already fixed, I didn't have time to check the tip - sorry) "modulo" replaced with "rem" inappropriately in a comment src/libstd/base64.rs line 118 "Divide by zero" error string became "Quotient of zero" src/libstd/num/rational.rs line 54 src/librustc/middle/trans/base.rs line 788, 790 src/test/compile-fail/eval-enum.rs line 2,3 Regards, Erik On 4/23/2013 11:46 AM, Graydon Hoare wrote: > On 23/04/2013 8:53 AM, Diggory Hardy wrote: > >> I suspect (please correct me if I'm wrong) that if it wasn't for C >> and x86 >> compatibility then most people would fall into two categories: don't >> know/don't care, and prefer F-division. It's one of those little >> things like >> tau vs. pi which would have been less confusing if we'd started off >> on the >> other foot to start with. > > And IP addresses would have been 64 or 128bit from the start, there > would only be one endianness, and so forth ... yes, sure. But we > don't cast off the weight of the past so easily, and I do not think > this is something it's wise to fiddle with. > > A very widely-applied design choice in rust is that the basic types > are machine-sized and the arithmetic operations on them are (as close > as reasonable to) machine operations. The machine operation is remainder. > > Moreover, it's not "just C and x86". This same choice is taken (more > or less) by PowerPC, LLVM, C++, C#, Java, D, Go, JS, Scala, Ocaml, > etc. etc. > > The path we've taken here is to admit _two_ operation-pairs, div/mod > and quot/rem. This path is taken by several languages and specs > (Scheme, Common Lisp, Ruby, Smalltalk, SML, Prolog, Haskell, Ada, and > ISO 10967 and IEEE 754). The work for this landed last week: > > https://github.com/mozilla/rust/pull/5990 > https://github.com/mozilla/rust/pull/6013 > https://github.com/mozilla/rust/issues/4565 > https://github.com/mozilla/rust/issues/4917 > > (Phew! This must really be the week for integer division!) > > The only remaining thing to struggle with is "which of the two > operation-pairs to assign the / and % symbols to", in the > operator-overloading sense. For this, we've gone with quot/rem, as in > the other languages above, and in keeping with the design preference > above. You have to call .mod() or .div() to get the other operators. > > It does mean there's a bit of a footgun surrounding the symbols / and > % specifically, on signed integer types. I would not be at all opposed > to adding a lint flag to calls-to-/-and-%-on-signed-integer-types, > such that you could trap them all. As with many things here, the > design space includes a variety of (sensible) preferences. > > -Graydon > > (Please correct me if I've swapped which of the two meanings we've > actually assigned; this is one of those issues like double-negation > and off-by-one indexing where I get things backwards no matter how > much energy I spend on making sure I get it right.) > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
