Another idiom I wish were gone from phobos/druntime
Zach the Mystic via Digitalmars-d
digitalmars-d at puremagic.com
Sun Feb 8 09:53:12 PST 2015
On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
> "Zach the Mystic" wrote in message
> news:qxtyqdeewrjurmwhksbj at 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!
More information about the Digitalmars-d
mailing list