<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">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.</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div>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.</div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">----------------</span></div>
Date: Fri, 14 Jan 2011 17:59:52 +0100<br>From: Edi Weitz <<a href="mailto:edi@weitz.de" style="color: rgb(20, 125, 186); ">edi@weitz.de</a>><br>Subject: Re: [pro] Style issue about predicates<br><br>There are lots of functions in the standard which are predicates in<br>
that they return generalized booleans but on the other hand return<br>something "useful" if the result is not NIL, e.g. MEMBER or STRING<.<br>I think this is good practice, i.e. return something other than T in<br>
case this might make more sense.  Of course, this should then be<br>documented in the predicate's contract and thus should be OK to use by<br>the caller.</span>