Bad array indexing is considered deadly

[Timon Gehr via Digitalmars-d]

On 01.06.2017 21:48, Walter Bright wrote:
> On 6/1/2017 12:16 PM, Timon Gehr wrote:
>> On 01.06.2017 20:37, Walter Bright wrote:
>>> It is a programming bug> to not validate the input. It's not that bad 
>>> to abort programs if you neglected to validate the input.
>>> ...
>>
>> It really depends on the specific circumstances.
> 
> The stages of programming expertise:
> 
> 1. newbie - follows the rules because he is told to
> 2. master - follows the rules because he understands them
> 3. guru - breaks the rules because he understands the rules don't apply
> 
> Let's not skip stages :-)
> ...

This does not really say anything about programming expertise, it says 
that "the rules" (whatever those are) are incomplete (unless there are 
no gurus, but then the list is nothing but silly).

I guess "terminate the program upon detection of a bug" is one of your 
rules. It's incomplete, but the language specification enforces it (for 
a subset of bugs).

> 
>>> It is always bad to treat programming bugs as input errors.
>> They should be treated as bugs, but isn't it plausible that there are 
>> circumstances where one does not want to authorize every @safe library 
>> function one calls to bring down the entire process?
> 
> You, as the programmer, need to decide what is validated data and what 
> is not.

There is not only one programmer and not all programmers are me.

> Being unclear about this is technical debt that is going to 
> cause problems.
> ...

This is both obvious and not answering my question.

> Validated data that is not valid is a programming bug

Again, obvious.

> and the program should be aborted.

The buggy subprogram should be. Let's say I want to use library 
functionality written over the course of years by non-computer scientist 
domain expert Random C. Monkey. The library is an ugly jungle of special 
cases but it is mostly correct and makes it trivial to add feature X to 
my product. It's also pure and @safe without any @trusted functions. I 
can still serve customers if this library occasionally misbehaves, at a 
lower quality. (Let's say it is trivial to check whether the code 
returned a correct result, even though building the result in the first 
place was hard.) I cannot trust Mr. Monkey to have written only correct 
code respecting array bounds and null pointers, but if my product does 
not (seem to) have feature X by tomorrow, I'm most likely going out of 
business. Now, why exactly should any of Mr. Monkey's bugs terminate my 
entire service, necessitating a costly restart and causing unnecessary 
frustration to my customers?

I'm pretty sure D should not outright prevent this use case, even though 
in an ideal world this situation would never arise.