alwaysAssert() [was: Against enforce()]

[Andrei Alexandrescu]

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