For my own code, sometimes it is to ensure I have a number somewhere that a number is required, eg when calling a function that treats undef differently (".. or if bool is undef, starts a game of nethack"), or badly ("use of uninitialised value"), or for storing in a NOT NULL database field. Another reason is where I need to use a different criterion for truthfulness:

  sub has_file {
    my $self = shift;
    my $filename = $self->filename;
    (defined($filename) && length($filename)) ? 1 : 0;
  }
[download]

Primarily, though, it is for clarity: to make it clear in the code (and to allow me to make it clear in the docs) that this routine returns either 0 or 1 and nothing else. I think the concept of a boolean value is very useful, and have always considered it a shame that perl didn't have such a thing as a first class data type.

The main benefit is to prevent leakage, both actual and conceptual. By 'actual', I mean returning (say) an object (that is of course TRUE in a boolean context) that means the reference count on the object is bumped, and the object may no longer be released when it could otherwise have been because someone is still holding on to the (conceptual) boolean that tells them whether they actually had the object.

Similarly if such a quasi-boolean is used in some polymorphic context, it may do entirely the wrong thing: there are many examples of methods that allow a parameter to be any of (0 or 1 or a coderef), and various other cases where a particular type of object is allowed.

The conceptual leakage is about clarity of thinking: if I am not sure that I have a true boolean value, I need always to consider whether it will do the right thing when I'm passing it around or using it in various ways. When I know that I definitely have either 0 or 1, my mind is freed to consider it in a much more simplistic fashion, and I can throw it around confident that it won't blow up in my face.

Hugo