Bad array indexing is considered deadly

[Jonathan M Davis via Digitalmars-d]

On Wednesday, May 31, 2017 23:13:35 Moritz Maxeiner via Digitalmars-d wrote:
> On Wednesday, 31 May 2017 at 22:47:38 UTC, Steven Schveighoffer
> wrote:
> > Again, there has not been memory corruption.
>
> Again, the runtime *cannot* know that and hence you *cannot*
> claim that. It sees an index out of bounds and it *cannot* reason
> about whether a memory corruption has already occurred or not,
> which means it *must assume* the worst case (it must *assume*
> there was).

Honestly, once a memory corruption has occurred, all bets are off anyway.
The core thing here is that the contract of indexing arrays was violated,
which is a bug. If we're going to argue about whether it makes sense to
change that contract, then we have to discuss the consequences of doing so,
and I really don't see why whether a memory corruption has occurred
previously is relevant. We could easily treat indexing arrays the same as as
any other function which chooses to throw an Exception when it's given bad
input. The core difference is whether it's considered okay to give bad
values or whether it's considered a programming bug to pass bad values. In
either case, the runtime has no way of determining the reason for the
failure, and I don't see why passing a bad value to index an array is any
more indicative of a memory corruption than passing an invalid day of the
month to std.datetime's Date when constructing it is indicative of a memory
corruption. In both cases, the input is bad, and the runtime doesn't know
why. It's just that in the array case, the API of arrays requires that the
input be valid, whereas for Date, it's acceptable for bad input to be
passed. So, while I can appreciate that you're trying to argue for us
keeping RangeError (which I agree with), I think that this whole argument
about possible, previous memory corruptions prior to the invalid index being
passed is derailing things.

The issue ultimately is what the consequences are of using an Error vs an
Exception, and _that_ is what we need to discuss.

- Jonathan M Davis