Another idiom I wish were gone from phobos/druntime

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 5 01:43:43 PST 2015


On Thursday, February 05, 2015 08:31:08 via Digitalmars-d wrote:
> On Thursday, 5 February 2015 at 08:25:56 UTC, Jonathan M Davis
> wrote:
> > 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 -
>
> The difference is that implementation asserts() are part of
> debugging within a module, while contracts may be active in
> release mode so that you know which module failed and which
> subcontractor to call to fix it.

There is no such difference in the current implementation. assertions inside
of in and out blocks are no different from assertions inside of the
functions themselves with regards to when they are compiled in or not. The
_only_ difference between having an assertion inside of an in block and
having it at the beginning of the function is that if the function is a
virtual function, then the rules of inheritance of DbC are taken into
account, which IIRC means that only one of the functions in the inheritance
chain has to have its in block pass, and the others are allowed to fail,
whereas if it were an out block, all of them would have to pass. Regardless,
if you have

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

it's _identical_ to

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

with regards to semantics. Ideally, what's in the in block would be compiled
in if the caller is compiled with assertions enabled with no regard to
whether the library with foo in it was compiled with assertions enabled or
not, but that's not how it works. And because D allows for function
prototypes where the implementation is hidden, it's not at all obvious how
it would even be possible for anything in an in our out block could be
compiled in or not based on the caller rather than the function itself.

- Jonathan M Davis



More information about the Digitalmars-d mailing list