On Thursday, 5 February 2015 at 08:37:07 UTC, Jonathan M Davis
wrote:
If you're not doing exhaustive unit testing, you're almost
certainly doing
it wrong.
That would be a NP-Hard problem for any function that takes an
array as input? :-)
And what you _can_ test when a function is exiting without
knowing
exactly what the input was and what the corresponding output is
supposed to
be is so minimal to be borderline useless.
You know what the input is, that is the point of a postcondition.
IF and ONLY IF the precondition holds, then the postcondition
holds.
Without a postcondition, the precondition is meaningless.
Even something
like sqrt can't be checked, because you'd need to know what the
input was
Sure you know. And it is cheap to test too if you have
"precondition(isreal(input))" then you get a fully specified
"postcondition(output*output==input)".
Keep in mind that contracts are for checking interoperability
between cohesive units/modules/components.
If you have a subcontractor that delivers a probe with a driver
then you might want the precondition to be that given input
(true,false) you get output in the range <0.0,1.0].
The subcontractor who writes the analytical component will have
to make the analyser work for all inputs from the probe in the
range <0.0,1.0].
When you scale up then the problem is that people make
assumptions about how things work, which they have not
implemented themselves. So testing interaction between components
may be useful even after deployment. Especially if involves
plugins, dynamic loading of code, hardware that is replaced...
which out blocks don't have access to (and really can't have
access to in
the general case - e.g. an input range can't be saved, and it
would be
mutated as part of the function's operations).
That's a D flaw. Not a flaw with pre/postconditions and contracts.
And even if you did have the
input, to check whether the output was correct, you'd have to
have some sort
of simple test based solely on the input that told you whether
the input was
correct, and in many cases, that would basically mean
reimplementing the
function.
No, the interface contract is part of the specification. The
implementor has to make an implementation that makes the
interface contract checkable if that is part of the deal.
Anything less would be a legal contract violation.
But the interface contract could be as simple as stating that the
input is always in a given range. Then the implementor will only
have to check for errors in that range and handle "exceptional
situations" that arise within that range in a graceful manner.
special outside of virtual functions, and they're very noisy
visually,
making them a huge detractor. So, personally, I don't think
They are noisy and the language and libraries should be improved
so that they can be useful for tool writers. But the language
should keep the precondition and postcondition together and make
them distinct from internal debugging statements. Contracts are
meant to be exposed externally. That's a key point that makes
them different from asserts.
be used outside of virtual functions. All of the supposed
benefits are
theoretical and don't seem likely at all to materialize any
time soon - if ever.
It will probably materialize if the language is adopted for large
scale projects...
Having explicit statements for preconditions and postconditions
is useful for code readability. It is just the current syntax
that is annoying.
