[Library Stabilization] BigInteger operator methods should have better argument names

[lydia-duncan]

All the operator arguments are named a and b except for the exponentiation and assignment operators which have appropriate names. I think these should be lhs and rhs as appropriate, and arg for unary operators.

If folks agree, I think we should update the standard module guidance to recommend this.

[bradcray]

I agree we should come up with a standard practice here (and then apply it to ChapelBase and the like).

I wouldn't use lhs and rhs for the two operands to a + operator, say, because in programming, I think of lhs as meaning "the thing to the left of an assignment operator", not the first input argument to a binary math operator. But I'd be open to using those as the names for a = or += operator.

For a case like +, I'd also be up for using:

• x and y (which I think are strictly better than a and b unless there's a precedent for a and b that I'm not aware of)
• maybe lop and rop or op1 and op2 (but I prefer x and y over these myself (for succinctness; seem math-y))
• defining a way in Chapel to say that an argument's name cannot be named at the callsite / shouldn't be relied upon (or known?) and using that feature here. Since operators don't currently support a function call form, like +(a=1, b=2) this is inherently true for them currently; but we may want to support such a form someday (?).

For the previous bullet's reason, this question probably matters a lot more for operator-like methods in BigInteger like .add() since they can be called using pass-by-keyword.

[lydia-duncan]

18650 is related

[jabraham17]

22008 is related

[lydia-duncan]

We've decided not to adjust these for 2.0 since operators can't be called with named arguments. Removing the 2.0 label