Improve "Improve Contract Syntax" DIP 1009

[Jonathan M Davis]

On Saturday, November 04, 2017 14:12:08 Adam D. Ruppe via Digitalmars-d 
wrote:
> On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis
>
> wrote:
> > I'm very much of the opinion that proper unit tests pretty much
> > eliminate the need for out contracts.
>
> I think that sqrt example is just bad. Out contracts shouldn't be
> testing specific values, but rather ranges or nullness or other
> such things that arguably should be part of the return type, but
> just don't fit in the type system for whatever reason.
>
> Consider this:
>
> class A {
>          A clone()
>          out(result) { assert(result !is null); }
>          body {
>                  return new A();
>          }
> }
> class B : A {
>          override B clone() {
>                  return new B();
>          }
> }
>
> void main() {
>          A a = new B();
>          A c = a.clone();
> }
>
>
> The `clone` method defined in the base class arguably out to
> return a NotNull!A, encoding that contract in the type, but we
> can't really do that with D without breaking the inheritance -
> where B is statically defined to return B too, since NotNull!B
> isn't covariant to NotNull!A the way B is covariant to A. (At
> least not with any techniques I can think of at this time.)
>
> So you can't encode it in the return type... but you can encode
> it in the out contract for a runtime check.
>
> It also clearly documents that the subclasses must not return
> null (and can add their own restrictions to further subclasses).
> One problem I have with some of D's contracts right now is that
> they are convoluted, ugly code that make for passable internal
> unit tests, you can't reasonably display as documentation as part
> of the interface.
>
> But regardless, I say you should not think of out as tests. Think
> of it as type system extensions.

It's an interesting idea, but I use classes so rarely in D that I wouldn't
hit this use case often enough to even think about it. In fact, at the
moment, I don't think that I've _ever_ written a clone function in D, and I
probably wouldn't even bother with null checks (in general, not just with
clone functions), since the program will just segfault on me if I screw that
up, so it's not like it won't be caught, and with the way I write code, I
almost never have problems with null objects except in cases where I forgot
to initialize something, and that gets found _really_ fast in testing.

- Jonathan M Davis