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
