Instead of reporting bounds check violations like this:
runtime error: index out of range
We could report them like this:
runtime error: index 27 out of range for length 20
We've long assumed that it would be too expensive to provide this information in a panic. But I've done some experiments, and it seems not very expensive. Adding information for both index and slice expressions has a space overhead of about 0.8% (using the go binary as the guinea pig). There is approximately no performance overhead, other than the icache cost, as the non-panic instruction path is identical.
To first order, the cost is 2 extra instructions in each panic path. We'd go from
to
MOVQ AX, (SP)
MOVQ CX, 8(SP)
CALL panicindex(SB)
That's 5 to 14 bytes on amd64. Cost will vary somewhat based on circumstances (constant indexes, for instance). Also, stack frames might need to be a bit bigger due to the extra outargs space.
The main benefit is a improved debugging experience. Especially with slicing, when an out-of-bounds panic happens it is often not clear which part of the slice expression is to blame.
I think there's some need for discussion about what the panic strings would look like. Particularly for slice expressions, how do we report the message? Should we include just the two values which triggered the violation (low and high if low > high, or high and cap if high > cap), or report all the slice args + the cap? Also, should we provide some programmatic way of accessing the failing index values, or just provide an updated string? (I vote the latter.)
This proposal was sort of discussed in #29435. The two main objections were the overhead (discussed above) and the fact that people might be depending on the text of the current messages.
Instead of reporting bounds check violations like this:
We could report them like this:
We've long assumed that it would be too expensive to provide this information in a panic. But I've done some experiments, and it seems not very expensive. Adding information for both index and slice expressions has a space overhead of about 0.8% (using the go binary as the guinea pig). There is approximately no performance overhead, other than the icache cost, as the non-panic instruction path is identical.
To first order, the cost is 2 extra instructions in each panic path. We'd go from
to
That's 5 to 14 bytes on amd64. Cost will vary somewhat based on circumstances (constant indexes, for instance). Also, stack frames might need to be a bit bigger due to the extra outargs space.
The main benefit is a improved debugging experience. Especially with slicing, when an out-of-bounds panic happens it is often not clear which part of the slice expression is to blame.
I think there's some need for discussion about what the panic strings would look like. Particularly for slice expressions, how do we report the message? Should we include just the two values which triggered the violation (low and high if low > high, or high and cap if high > cap), or report all the slice args + the cap? Also, should we provide some programmatic way of accessing the failing index values, or just provide an updated string? (I vote the latter.)
This proposal was sort of discussed in #29435. The two main objections were the overhead (discussed above) and the fact that people might be depending on the text of the current messages.