Why does out-of-bounds array indexing/slicing clamp to the last array value?

[mikex-oss]

I was surprised while reviewing DSLX code to see that something like

let my_array: u32[4] = [u32:0, u32:1, u32:2, u32:3];
slice(my_array, u32:4, u32[4]:[0, ...])

evaluates to [u32:3, ...].

@ericastor pointed out that while this is not described in the DSLX reference, it is covered in the IR documentation:

If any element in that segment is out-of-bounds of the original array the value at the corresponding index is the final element in the array. This is consistent behavior with respect to the index operation.

The index operation then says:

Any out-of-bounds indices idx_{i} are clamped to the maximum in bounds index for the respective dimension.

So the behavior seems to be WAI. This, however, leaves open the question...why is this intended?

It doesn't seem to be guided by Rust principles, as Rust either errors on compilation (for const expressions) or panics at runtime otherwise -- https://doc.rust-lang.org/reference/expressions/array-expr.html#array-and-array-index-expressions, https://doc.rust-lang.org/book/ch03-02-data-types.html#invalid-array-element-access

SystemVerilog handles out of bounds indexing with either X for 4-state integral arrays or 0 for 2-state, so it doesn't match RTL either (LRM 7.4.6).

Is there context/motivation for the current behavior? I worry that this is a footgun that will be surprising to many hardware engineers.