Another idiom I wish were gone from phobos/druntime

[Jonathan M Davis via Digitalmars-d]

On Thursday, February 05, 2015 17:42:11 Daniel Murphy via Digitalmars-d wrote:
> "Meta"  wrote in message news:ejqtxksoifmqzetllaqw at forum.dlang.org...
>
> > I don't know about others (besides Beatophile, who religiously adheres to
> > writing contacts), but putting contracts on functions is a hassle. I never
> > do it unless I'm feeling particularly full of divine fervor. It's a lot
> > like making all variables that don't need to be changed immutable (another
> > thing which only Bearophile seems to do) or properly documenting code.
> > Strong optimization guarantees from contracts would go a long way in
> > convincing people to actually write them (although I guess that's not what
> > you want; Perhaps you changed your mind). It's a chicken and egg problem.
>
> Would you be more likely to write contracts if something like this was
> implemented?
> https://github.com/D-Programming-Language/dmd/pull/3799
>
> I want to check contracts at compile time, when possible.  For me this would
> make contracts 1000x more useful.

If the semantics of

auto foo(T arg)
in
{
    assert(something about arg);
}
body
{
    ...
}

and

auto foo(T arg)
{
    assert(something about arg);
    ...
}

actually are different, and the in block provides a useful difference, then
there's value in having in blocks. Without that, IMHO, they're just visual
noise, even if you use a different coding style that condenses them more,
e.g.

auto foo(T arg)
in {  assert(something about arg); } body {
    ...
}

So, if we can change the semantics of in and out blocks so that they provide
actual value, then there's definitely value in using them. But until then,
as far as I'm concerned, they're just cruft that should be avoided.

Having some sort of compile time checking of contracts would potentally be a
case where in blocks would be of value, though I really don't see much
difference between checking the assertions in an in block and checking any
other assertions at compile time that can be checked at compile time -
especially if they're at the beginning of a function.

The real killer feature would be if we could figure out how to make it so
that contracts are controlled by the call site instead of being compiled out
when the function itself is compiled without assertions enabled. But I have
no idea how we could do that given that we can have function prototypes
without the actual source code being visible at the call site.

- Jonathan M Davis