On Thursday 25 April 2013 09:25:30 Graydon Hoare wrote:
> While it's true that people often pronounce % as "mod", the fact is most
> of the languages in the lineage we're looking at treat it as "rem".
> 
> http://en.wikipedia.org/wiki/Modulo_operation
> 
> 50 languages in that list expose 'remainder' and 19 of them map it to
> '%'. As well, as a "systems language", it _is_ salient that the
> instructions on the CPUs we're targeting and the code generator IR for
> said machines (LLVM) expose a remainder operation, not a modulo one. Of
> the 35 languages that expose _anything_ that does "proper mod", only
> interpreted/script languages (TCL, Perl, Python, Ruby, Lua, Rexx, Pike
> and Dart) call it %. That's not our family. I'm sorry; if we're arguing
> over "what the % symbol means", it means remainder in "our" language
> family (the one including C, C++, C#, D, Go, F#, Java, Scala).
> 
> (more gruesome comparisons available here:
> http://rigaux.org/language-study/syntax-across-languages/Mthmt.html#MthmtcDB
> QAM )

Good argument.

> There are other questions to answer in this thread. We had a complex set
> of conversations yesterday on IRC concerning exposure of multiple named
> methods for the "other variants" -- ceiling, floor and truncating
> division, in particular. We may need to expose all 3, and it might be
> the case that calling any of them 'quot' is just misleading; it's not
> clear to me yet whether there's a consistent method _name_ to assign '/'
> to (floating point divide seems to do the opposite of integer divide on
> chips that have both).
> 
> But I don't think it's wise to map % to 'mod' if we're exposing both
> 'mod' and 'rem'. That's a separate issue and one with (I think) a
> simpler answer for us.

'system_divide' or 'hardware_divide' would make it clear that it's intended to 
do what the hardware provides, if that's what matters. Or 'c_div' if it's 
meant to be C compatible.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to