Improve "Improve Contract Syntax" DIP 1009

[Jonathan M Davis]

On Sunday, November 05, 2017 16:25:16 MrSmith via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 15:38:42 UTC, Jonathan M Davis
>
> wrote:
> > In principle, that would be nice, but in practice, it's not
> > really feasible. In the general case, there's no way to save
> > the state of the parameter at the beginning of the function
> > call (you could with some types, but for many types, you
> > couldn't). IIRC, it's been discussed quite a bit in the past,
> > and there are just too many problems with it.
> >
> > - Jonathan M Davis
>
> What about making definitions in "in" block visible in "out"
> block?
>
> void fun(int par)
> in {
>      int saved = par;
> }
> body {
>      par = 7;
> }
> out {
>      writeln(saved);
> }

That would help, and I think that that it was discussed previously, but it
would mean that in and out were in the same scope, which would be a breaking
change. There may have been other reasons why it would be problematic, but I
don't recall. There's certainly nothing stopping the creation of a DIP on
the topic though if someone feels strongly enough about it to put in the
time and effort.

I'm sure that there are various things that could be done to improve
contracts (and DIP 1009 is one such attempt), but I've mostly given up on
it. I don't think that they provide enough value in the first place. Aside
from issues involving contracts and inheritance, in contracts can just be
put in the function body, making them kind of pointless, and for the most
part, unit tests test anything that I would consider testing in an out
contract - and generally do it better. That combined with the issue with
invariant and void initialized objects, and as far as I'm concerned,
contracts are pretty pointless, much as they're well-intentioned. I almost
never use them.

Probably the one thing that would make me change my tune on in contracts
would be if it were somehow changed so that whether they were run depended
on whether the caller was compiled with assertions enabled rather than
whether the function being called was compiled with assertions, since with
in contracts, it's really the caller that you're testing, not the function
itself. But short of that, I doubt I'll ever do much with them.

However, one thing that annoys me enough that I might do something about it
at some point is how invariant is broken with void initialized objects,
since unlike in and out contracts, doing what invariant does without using
the feature is a royal pain. So, at some point, I may create a DIP to deal
with that (probably by providing a way to explicitly indicate that you want
the invariant skipped at the callsite), but it hasn't been a particularly
high priority for me, so I haven't done anything with it.

- Jonathan M Davis