On the other hand, I've been dealing with that in the past, and I agree
that it would have been very helpful having @OperationRename, at least for
prototyping. What I did in the past, was to create an extension for the
specific library in order to be able to use operators everywhere in the
We could go with an AST transform specifically for fixing "mod" but I don't
think it is accurate to say the feature isn't wanted in its own right.
We already do the same kind of rename using runtime metaprogramming all the
time, we would now just have a way to do it using compile-time
Hi Paul,
@mod -> remainder: I am glad you went with the clean solution of a
breaking change; sometimes alas that is the only good option, and, as
you said, every other (clever) approach just feels like putting a
band-aid on a band-aid, ultimately ending in a mess.
@OperationRename: That
The idea of fixing inconsistencies is great. I also like the idea of giving
a mid-term solution for those using the mod operator "incorrectly". But I'm
not sure about opening the door for precisely overloading operators with
different names than the ones specified by default, that seems to be just
Hi folks,
It has been a while but I finally got back around to this issue.
As a reminder, this issue is about using "mod" as the name of the method
for the "%" operator. Both remainder and mod are the same for positive
numbers, and we are guilty in informal contexts of sometimes conflating the
Hi folks,
As part of fixing GROOVY-10800, I was planning to make the behavior
for the "%" operator for BigInteger be consistent with our other data
types (and with Java).
Basically, there is a distinction between "remainder" and "modulo" for
negative numbers.
For the expression "numerator op
