On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
"Zach the Mystic" wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign
different from the first. If you assert (anything but
assert(0)) first thing, you certainly are not checking for
bugs *within* the function - you're checking for entry
conditions. So the question is whether the practical
difference between the two asserts above is sufficient to
prevent applying the syntax sugar. I personally can live with
it either way (I can handle being told the the function failed
when it was really the caller that failed), but it's a
judgment call. I mean, this thread was literally called
"Another idiom I wish were gone from phobos/druntime." I don't
expect it is the last time someone will complain about it.
Here's one:
struct S
{
private:
static int instanceCount;
...
public:
void func(int x)
in
{
assert(x >= 0, "can't call func with negative x");
}
body
{
assert(instanceCount > 0);
}
}
The first assert checks something the caller has control over,
the second assert is a sanity check, and if it fails it's not
an error in the caller.
Well, okay. This is a case where there is a slight practical
difference. In the spirit of keeping the rare case possible, I
would suggest:
body
{
{} // reject in-contract assert
assert(instanceCount > 0);
}
Anyway, IMO there is zero chance of this making it into the
language and you're wasting your energy.
That's disappointing, but I didn't waste my energy. I realized
there's validity to both sides of this argument (bulky contracts
vs. accurate errors), and instead of choosing a side, I tried to
come up with the biggest total win for both sides. I think my
solution is a 80-90% win for both sides, which is better than
100-0% for just one. If it gets rejected for some other reason,
so be it. I'm trying to help, here!
