Another idiom I wish were gone from phobos/druntime

[via Digitalmars-d]

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.