@bmkessler

I added the proposal label, as this is kind of a mini-proposal.

Change https://golang.org/cl/144377 mentions this issue: math/bits: define Div to panic when hi>=y

A panic can be recovered. Would it make sense to throw instead?
(Almost equivalently, do we expect folks using math/bits to fuzz-test their programs?)

Either way, the carry and borrow bits for Add and Sub should probably get a similar treatment.

We should instead define it to panic in that case.

Thinking about this some more, I strongly disagree. If we define it to panic, then we are inviting users to throw whatever garbage they want at the API and use recover to clean up the mess. It seems preferable to keep the definition of the API such that invalid inputs are unambiguously a caller-side bug.

That way, we would remain free to do something reasonable and consistent — including panic! — in the concrete implementation, but we would also remain free to take other reasonable actions — such as rejecting the program at compile-time — in cases where we have more information available.

For integer division, the language spec states that if the divisor is a constant, it must not be zero, but it handles division by zero at runtime with a runtime panic similar to this change for overflow.https://golang.org/ref/spec#Integer_operators

If the divisor is a constant, it must not be zero. If the divisor is zero at run time, a run-time panic occurs.

Would a preferable wording explicitly label this as a runtime behavior, leaving open the option to validate arguments at compile time as a future possibility? I'm not aware of other functions that currently have compile-time argument validation.

As for Add and Sub, a more foolproof API might actually be to use booleans for the carry since they are just a single bit. That would eliminate any possible mis-use at a cost of a slightly different API.

As for Add and Sub, a more foolproof API might actually be to use booleans for the carry since they are just a single bit. That would eliminate any possible mis-use at a cost of a slightly different API.

I don't think booleans for the Add and Sub carry would be an improvement, since the caller would just end up writing a boilerplate function anyway (and either do the obvious panic that we could do ourselves, or ignore the possibility of invalid inputs in their own function). Moving the misuse to the caller does not eliminate it. 🙂

@bcmills Given that the language panics on division by zero, I think it is consistent for math/bits.Div to panic in a similar situation.

On a different point, I think that experience with rejecting constant division by zero at compile time has shown that that was a mistake. We should not be rejecting invalid operations at compile time. That just makes life painful for people who use build tags to control their constants, and who check for a zero divisor before executing the division.

Change https://golang.org/cl/149517 mentions this issue: math/bits: define Div to panic when y<=hi

Given that the language panics on division by zero, I think it is consistent for math/bits.Div to panic in a similar situation.

That's a good point. Much as I don't want to specify control-flow behavior for something that ~always indicates a programming error, consistency with the existing control-flow behavior for division by zero is compelling.

On a different point, I think that experience with rejecting constant division by zero at compile time has shown that that was a mistake. We should not be rejecting invalid operations at compile time.

I gave the example of rejecting an error at compile time as an example, but perhaps it's not the best example of a useful alternative behavior.

My broader point is that panic and recover are defined as control-flow constructs, not program errors: if an expression actually does panic at run-time but the panic is recovered (or the program stalls while evaluating deferred calls), dynamic tools (like the race detector) cannot report that expression, even during testing, even though the panic is nearly always a symptom of an error in the program logic.