One might think that the way to test a value for being logic truth is TRUE?...though that's misleading, since all values except LOGIC! false and BLANK! are true. Similarly, FALSE? doesn't just test for LOGIC! false... it also says blank is false.
(Note: If you've found yourself writing things like all [logic? foo | foo]
...that is more succinctly done as foo = true
.)
In any case, TRUE? is a somewhat rare operation...because usually testing for "truthiness" is implicit in conditional operations. You don't have to say if true? foo [...] or case [true? foo [...] ...]. The only real time you would use it would be to coerce things to a logic, which is covered by TO-LOGIC in modern Ren-C (which doesn't consider 0 to be false as Rebol2 did. I managed to get this change accepted to Github rebol/rebol back around the time of the open sourcing.)
@earl argued that TRUE? was somewhat more readable, but a lot has changed with chaining. Getting a logic result from FIND is now done with FIND? instead of TRUE? FIND
(or FOUND? FIND
), and other routines have XXX? forms that are chained into TO-LOGIC. So I believe this swings the balance to where having a misleading operation that people might be tempted to use to mean = true or = false is simply not worth it.
So anywhere you would have used FALSE? instead use NOT. Anywhere you would have used TRUE? instead use TO-LOGIC,. And we kill these misleading operations.
It appears that Red has gone with the change in TO as well, so the same approach should work for them:
--== Red 0.6.2 ==--
Type HELP for starting information.
>> to-logic 0
== true
>> to-logic 1
== true
>> to-logic none
== false
>> to-logic false
== false
>> to-logic true
== true