Bad array indexing is considered deadly

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 3 June 2017 at 11:18:16 UTC, Paolo Invernizzi wrote:
> Sorry Ola, I can't support that way of working.
>
> Don't take it wrong, Walter is doing a lot on @safe, but 
> compilers are built from a codebase, and the codebase has, 
> anyway, bugs.
>
> I can't approve a "ok, do whatever you want in the 
> validate_input and I try to *safely* throw"

If the compiler is broken then anything could happen, at any 
time. So that merely suggests that you consider the current 
version to be of beta-quality.

Would you make the same argument for Python?


> IMHO you can only do that if the validator is totally 
> segregated, and to me that means in a separate process, neither 
> in another thread.

Well, that would be very tedious.

The crux is:

The best way to write at good validator is to make the code in 
the validator as simple as possible so that you can reduce the 
probability of making mistakes in the implementation of the spec.

If you have to add code for things like division-by-zero logic 
flaws or out of bounds checks then you make it harder to catch 
mistakes in validator and increase the probability of a much 
worse situation: letting illegal input pass.

So for a validator I want to focus my energy on writing simple 
crystal clear code that only allows legal input to pass. That 
makes the overall system robust, as long as the language is 
capable of trapping all the logic flaws and classify them as a 
validation-error.

So there is a trade off here. What is more important?

1. Increasing the probability of correctly implementing the 
validation spec to keep the database consistent.

2. Reduce the chance of the unlikely event that the 
compiler/unsafe code could cause the validator to pass when it 
shouldn't.

If the programmer knows that the validator was written in this 
way, it also isn't a big deal to catch all Errors from it. 
Probabilistically speaking, the compiler being the cause here 
would be a highly unlikely event (power failure would be much 
more likely).

> To me, pragmatic means that the B2B website has to be organised 
> in a way that the impact is minimum if one of the processes 
> that are handling the requests are restarted, for a bug or not. 
> See Laeeth [1]. Just handle "insignificant requests" to a 
> cheeper, less robust, less costly, web stack.

Then we land on the conclusion that development and running cost 
would increase by choosing D over some of the competing 
alternatives for this particular use case.

That's ok.