Another idiom I wish were gone from phobos/druntime

[Jonathan M Davis via Digitalmars-d]

On Thursday, February 05, 2015 08:13:31 via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 08:01:06 UTC, Jonathan M Davis
> wrote:
> > the function exits, but in the vast majority of cases, what
> > you're testing
> > with an out contract is what unit tests would be testing, in
> > which case, the
> > out blocks don't really add anything, and since they're forced
> > to be
> > general, you can't test for specific results like you can with
> > a unit test.
>
> That would be true if:
> - the unit test was doing exhaustive testing
> - the unit test is fully specified
> - the unit test is proven correct

If you're not doing exhaustive unit testing, you're almost certainly doing
it wrong. 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. For something like sort, you can
check that the range is sorted on exit (though that's so expensive to check
that it's kind of ridiculous to check it on every call), but for most
functions - even basic functions - you can't check anything. Even something
like sqrt can't be checked, because you'd need to know what the input was,
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). 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.

In my experience, unit tests are far more valuable than any assertions
inside of a function could be for verifying that a function's output is
correct.

> But post conditions that are part of a specification can in
> theory be used for optimization when you link object files from
> different sources. So you can change the implementation of one
> object file with only linking as long as the specification itself
> does not change. Well, if you had a separate specification...

Right there. That's the problem. People keep coming up with ideas about how
in blocks and out blocks could _theoretically_ be useful. But as it stands,
there's nothing special about them at all, and the fact that D can use
separate compilation tends to kill most suggestions of actually doing
anything special with them. So, as it stands, in and out blocks do _nothing_
special outside of virtual functions, and they're very noisy visually,
making them a huge detractor. So, personally, I don't think that they should
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.

- Jonathan M Davis