http://d.puremagic.com/issues/show_bug.cgi?id=8672
--- Comment #7 from bearophile_h...@eml.cc 2012-09-16 19:16:51 PDT --- (In reply to comment #6) > since there is no standard definition for it, Most computer languages have one of two definitions. C99 and D use one, I am talking about the other one. So you can say there are two "standards". Many of the languages that use the C99 definition are C++/Java/C#/D/Go that are designed like this just because they are copying C, not because the C % is the better one. > The whole point is that there's nothing wrong with how % works, The definition of % in C is not the most intuitive, it's not the one you usually want when you code using negative numbers, and I think it's more bug-prone because you sometimes forget all this. Python and Haskell designers think that it's bad, they have not chosen randomly one of the two designs throwing a coin. Python designers have broken the C "compatibility" on purpose on this. It's documented. Despite some flaws, Python and Haskell are two of the best designed-out languages around, when they do something the same way, it's probably not a random occurrence :-) If you perform a Google search using some right words you find many results that show/discuss the problem, it's not a problem created by my mind: http://stackoverflow.com/questions/1082917/mod-of-negative-number-is-melting-my-brain http://stackoverflow.com/questions/9050209/weird-results-of-modulo-arithmetic-with-negative-numbers-and-unsigned-denominato > and D implements it in one of the ways that's > very common, even if it's not what you might what. This is right, it's very common. But you can see I have never asked to change the % operator of D. I am aware of the importance of keeping it compatible with C. > And it's not worth adding > another operator for another variation of how modulus could work. I can agree to this. > A function does the job just fine. It's not something that merits yet another > operator. If you take a look at my issue 7728, Walter has closed it too. issue 7728 asks for a function that is intrinsic. I think this is better than a normal function because D programmers will be more willing to use the alternative modulus if they know it's implemented by a very small number of _inlined_ asm instructions (or even one, on the CPUs that support this operation natively). This is a *basic* operation, it can't afford being slow. See here: http://code.google.com/p/go/issues/detail?id=448 >> There are two ways to do it: doing an extra (expensive) division ((m % n) + n) % n; or doing an extra (expensive) conditional temp = m % n if temp < 0: temp += n Hopefully the compiler will see that it can do a conditional move in the second case, but it's not obvious. << A function-looking compiler intrinsic avoids this. Once such intrinsic is present in Phobos I will stop remove the usage of % in my D code :-) > At this point, unless there's a huge advantage in putting > something in the language, we're just not going to do it. Even Fortran is now and then adding important features today. Generally only dead languages stop changing. Please keep this in mind. Saying that "the programmer needs to be aware of what result he is trying to achieve with negative numbers" misses the fact that the C % is usually not useful when you are working with negative numbers. This thread shows a lost opportunity for D. I am not going to agree with Walter or you on this. Python and Haskell are better on this, their % operator is more useful and safer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
