Just to clarify my earlier stance: I agree -- if there's something well-defined and more useful than T to return, return that. It's the 'null/non-null' contracts that are problematic.

The extra wiggle-room here offers no utility at all. It does allow for one branch of an implementation to avoid a constant load, or in some cases a test/branch and load. In this day and age, I do not find small constant bits of CPU compelling, in contrast to matters that affect reliability of large-scale software, when coded by real-world teams of programmers.

----------------

Date: Fri, 14 Jan 2011 17:59:52 +0100
From: Edi Weitz <edi@weitz.de>
Subject: Re: [pro] Style issue about predicates

There are lots of functions in the standard which are predicates in
that they return generalized booleans but on the other hand return
something "useful" if the result is not NIL, e.g. MEMBER or STRING<.
I think this is good practice, i.e. return something other than T in
case this might make more sense. Of course, this should then be
documented in the predicate's contract and thus should be OK to use by
the caller.