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.
