P0811R3 provides the standard definition for `std::midpoint`

over integral types as "Returns: Half the sum of `a`

and `b`

. If `T`

is an integer type and the sum is odd, the result is rounded towards `a`

.
Remarks: No overflow occurs."

The stated reasoning in the rest of P0811R3 is that (paraphrasing heavily) rounding towards *a* is typically what you'd expect when doing e.g. binary search. (Side note: this also allows the caller to control the rounding.)

P0811R3 also notes that you can change the condition to `a>=b`

or `a<=b`

to round half integers up or down, respectively.

From my understanding, there's five options:

- Round towards
`a`

- Round towards
`b`

- Round up (towards
`MAX`

)
- Round down (towards
`MIN`

)
- Round towards
`0`

Personally, I think only the first or the fifth options are really in the running to be picked. The first isn't commutative, but it has predictable and consistent behavior for ++, +-, -+, and --: bias towards the first argument. The fifth leans on the fact that integer division truncates toward zero for familiarity, and gains commutativity, but loses the consistency that `midpoint(x, y) == -midpoint(-x, -y)`

.

It's a trade-off. If always rounding toward zero can be done branchless and rounding toward `a`

can't, that'd make me more likely to support rounding toward zero, but I still think rounding toward `a`

is more useful. (Plus, if it inlines, you can just sort `a`

and `b`

on input to get the the rounding you want at no cost.)