alwaysAssert() [was: Against enforce()]

[Walter Bright]

On 3/17/2011 5:41 PM, Andrei Alexandrescu wrote:
>> if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
>> assert(0); }
>
> Note that you have (twice in two different posts)

That's because I used cut & paste.

> a bug in your code: you should have used writefln, not writeln.

I made a mistake, I should have tested it.

> This humorously ruins your point,

Come on. In any case, it would print:

my message %s %stest.d6
core.exception.AssertError at test(6): Assertion failure

and the information is still there, just badly formatted.


>> Furthermore, nothing prevents the user from writing his own alwaysAssert.
> Conversely, nothing prevents the library from defining a function if it deems it
> widely useful, even if short.

Right. So is it so widely useful that it justifies the cognitive load of 
documentation of it and filling up Phobos with trivial stuff? It's not just 
alwaysAssert(), this particular issue comes up again and again. The last time it 
was for a suite of math functions that took degrees instead of radians.

I think what we need in Phobos is nontrivial stuff. Things like the fast xml 
library, network code, database interface, etc.


>> For inclusion in Phobos, the more trivial something is, the higher
>> utility it needs to have to justify it. Of course, there's an element of
>> subjectivity to these judgments. One liners, though, should always be
>> subject to significant scrutiny and justification. Once in, we'll be
>> stuck with them for a long time.
>
> Correct. There are also other criteria such as standardization. Primitives for
> logging would score strongly on the standardization scale, though they are often
> trivial to implement.
>
> You rose things debug and unittest all the way up to coveted keyword status
> because you correctly understood that, although such items could have easily
> been left to the implementation, everybody would have chosen their own devices
> creating a morass of incompatibility. I find it incongruent that you so strongly
> believe such success cannot be reproduced.

There's a limited amount of such things one should do. Where does it stop?

Each addition must be judged on its own merits, not on the merits of something 
else. As many have pointed out, D does not follow any of its principles 100%, 
because doing so will drive it into a ditch, as do all things that value 
adherence to principle over utility.