revert the .truth conjecture

Shouldn't have speculated about .truth along with the .gist change,
so reverting that part.  Also, what conditionals do to break the
boolean circularity is left up to the implementation.

Author: TimToady

S02-bits.pod

@@ -4483,22 +4483,22 @@ containers (such as slice and hash context; see S03 for details).
 =item *
 
 Unlike in Perl 5, objects are no longer always considered true.
-It depends on the state of their C<.truth> method, which may either be
+It depends on the state of their C<.Bool> method, which may either be
 a synthetic attribute or an explicitly represented bit in the object.  Classes get to decide
 which of their values are true and which are false.  Individual objects
 can override the class definition:
 
     return 0 but True;
 
-This overrides the C<.truth> method of the C<0> without changing its
+This overrides the C<.Bool> method of the C<0> without changing its
 official type (by mixing the method into an anonymous derived type).
 
 =item *
 
-The definition of C<.truth> for the most ancestral type (that is, the
+The definition of C<.Bool> for the most ancestral type (that is, the
 C<Mu> type) is equivalent to C<.defined>.  Since type objects are
 considered undefined, all type objects (including C<Mu> itself)
-are false unless the type overrides the definition of C<.truth>
+are false unless the type overrides the definition of C<.Bool>
 to include undefined values.  Instantiated objects default to true
 unless the class overrides the definition.  Note that if you could
 instantiate a C<Mu> it would be considered defined, and thus true.

S03-operators.pod

@@ -3807,8 +3807,8 @@ because it will always choose the C<True> case.  Instead use something like
 a conditional context uses internally:
 
     given $boolean {
-        when .truth == 1 {...}
-        when .truth == 0 {...}
+        when .Bool == 1 {...}
+        when .Bool == 0 {...}
     }
 
 Better, just use an C<if> statement.  In any case, if you try to smartmatch

S04-control.pod

@@ -1219,7 +1219,7 @@ Whenever a new exception is stored in C<$!>, it becomes the new main
 exception, and if the old main exception is not marked as handled,
 it is pushed onto the internal list of unhandled exceptions.
 
-If you test a C<Failure> for C<.defined> or C<.truth>, it causes C<$!>
+If you test a C<Failure> for C<.defined> or C<.Bool>, it causes C<$!>
 to mark the main exception as I<handled>; the exception acts as a
 relatively harmless undefined value thereafter.  Any other use of the
 C<Failure> object to extract a normal value will throw its associated

S12-objects.pod

@@ -1962,28 +1962,29 @@ roles, and the enum values are really subset types of C<Int>, though the
 constant objects themselves know that they are of type C<Bool> or C<Taint>,
 and can therefore be used correctly in multimethod dispatch.
 
-You can call the low-level C<.truth> coercion on any built-in type, because
-all built-in types do the C<Boolean> role, which requires a C<.truth> method.
+You can call the low-level C<.Bool> coercion on any built-in type, because
+all built-in types do the C<Boolean> role, which requires a C<.Bool> method.
 Hence, there is a great difference between saying
 
         $x does Boolean;        # a no-op, since $x already does Boolean
         $x does Bool;           # create a $.Bool attribute, also does Boolean
 
 Conditionals evaluate the truth of a boolean expression by testing
-the return value of C<.truth> like this:
-
-    $obj.truth != 0
+the return value of C<.Bool>; how they do this is a mystery, except
+that they must do something mysterious and platform dependent to
+avoid calling C<.Bool> recursively on the results of C<.Bool>.
 
 Never compare a value to "C<True>".  Just use it
 in a boolean context.  Well, almost never...
 
 If you wish to be explicit about a boolean context, use the high-level
 C<so> function or C<?> prefix operator, which are underlying based
-on the C<.truth> method.  Also, use these high level functions when you wish
-to autothread junctions, since C<.truth> forces collapse of a junction's
-wavefunction.  (Similarly, C<.gist> forces stringification of the entire
-junction, while prefix:<~> does not.)  The C<.Bool> coercion also autothreads
-rather than collapsing.
+on the C<.Bool> method.  Since C<.Bool> always collapses junctions,
+so do these functions.  (Hence if you really need to autothread a
+bunch of boolean values, you'll have to convert them to some other
+type such as C<Bit> that can be used as a boolean value later.
+Generally it makes no sense to autothread booleans, so we have a
+policy of collapsing them sooner rather than later.)
 
 Like other type names and constant names, enum keynames are parsed as
 standalone tokens representing scalar values, and don't look for any

S32-setting-library/Basics.pod

@@ -90,10 +90,10 @@ declared.
 
 XXX Copied from S02 -- should it be deleted from there?
 
-The definition of C<.truth> for the most ancestral type (that is, the
+The definition of C<.Bool> for the most ancestral type (that is, the
 C<Mu> type) is equivalent to C<.defined>.  Since type objects are
 considered undefined, all type objects (including C<Mu> itself)
-are false unless the type overrides the definition of C<.truth>
+are false unless the type overrides the definition of C<.Bool>
 to include undefined values.  Instantiated objects default to true
 unless the class overrides the definition.  Note that if you could
 instantiate a C<Mu> it would be considered defined, and thus true.