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