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@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.

Reply via email to