On 3/17/11 7:16 PM, Walter Bright wrote:
On 3/17/2011 4:38 PM, dsimcha wrote:
On 3/17/2011 7:12 PM, Walter Bright wrote:
Sure, but there is plenty wrong with using enforce() for bug detection
even if alwaysAssert does not exist. For one thing, such uses encourage
others to misunderstand and misuse enforce.
Additionally, alwaysAssert is an obvious one liner. I think such things
need to be very frequently used to consider them part of the standard
library. Otherwise, we risk Phobos becoming a morass of trivia.
What makes you think it wouldn't be used very frequently?
I don't know if it would or would not be used very frequently.
It seems silly to me
to turn off asserts in non-performance-critical bits of code just
because I
don't want bounds checking or the more expensive asserts.
The use case is more constrained than that. Because of the existence of:
if (!condition) assert(0);
the alwaysAssert is constrained to those purposes where the user feels
the need for file/line/message for bug detection in released code, and
also does not want to use:
if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
assert(0); }
Note that you have (twice in two different posts) a bug in your code:
you should have used writefln, not writeln. This humorously ruins your
point, particularly because it's a bug likely to make it all the way to
production (since that code path would normally not be exercised).
Furthermore, the format of the message is decided with every call
instead of centrally.
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.
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.
Andrei
