Bad array indexing is considered deadly

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 31 May 2017 at 23:51:30 UTC, Jonathan M Davis wrote:
> 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.

Right, and that is why termination when in doubt (and the 
programmer has not done anything to clear that doubt up) is the 
sane choice.

> The core thing here is that the contract of indexing arrays was 
> violated, which is a bug.

I disagree about it being the core issue, because that was 
already established in the OP.

> 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.

Because if such a memory corruption occurred, termination of the 
closest enclosing scope to get rid of it must follow (or your 
entire system can end up corrupted).

> 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.

One of those is a library construct, the other is baked into the 
language; it is perfectly fine for the former to use exceptions, 
because it can be easily avoided by anyone; the latter is a 
required component of pretty much everything you can build with D 
and must thus use the stricter contract.

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

An Exception leads to unwinding&cleanup, an Error to termination 
(with unwinding&cleanup in debug mode for debugging purposes). 
What would you like to discuss here?