I understand. My point is that, in Racket, everything other than #f can be considered true. So, instead of returning (and x #t), you can simply return x. No code should be doing something like (if (equal? x #t) ... it should be simply (if x ...

Even and does this.

I don’t think functions named like foo? should ever not return a boolean, so there’s still reasons to coerce from falsy to real booleans occasionally

i understood you point @badkins but as I said before. even though other things may evaluate to #t, i expect the function to be return a real #t .. coming from strongly typed languages :slightly_smiling_face:

We had a similar division in Ruby about “truthiness”. I guess I keep coming back to the fact that I think it’s a very bad idea to have code that is comparing a value to #t directly, and if that’s the case, there’s no reason to cast a non-#f value to #t. If it’s simply an aesthetic preference, I can certainly understand that. It’s asymmetrical - i.e. casting to #t is fine if that’s more pleasant to the coder of the function returning a boolean, but OTOH comparing to #t explicitly is bad.

Now I’m curious if any built-in Racket predicates return anything other than #f or #t

I suppose one reason to return an explicit boolean is to allow specifying the type in a contract.

The documentation of intent is a very big deal and should not be undervalued

I agree w/ importance of documentation of intent. I think I’m just wrestling with consistency. In other words, if we’re only going to consider #f and non-#f in conditional statements such as if and cond, then I think predicates should be “typed” to return #f or non-#f. Conversely, if we’re typing predicates to return only one of {#f, #t }, then it should be an error to use something else in if and cond .

I mean I agree that my function could return non #f and be fine but I just don’t see any reason to not return #f. Call me stubborn but the answer I expect from a yes/no question is.. well yes or no. And the extra argument to and is surely not a performance issue in my code.

@dbriemann I totally get it, and I agree that it’s more neat & tidy to have a predicate return only one of two values #t or #f. And I think the 3 of us in the thread agree that we shouldn’t be comparing a value to #t explicitly in a conditional. It’s the combination of those two perspectives I’m having trouble reconciling, but it’s likely only a problem for me, so no biggie.