Closes #2321 (#2325)

* Closes #2321

* Correction of indefinite/definite typo in earlier commit

Author: threadless-screw

doc/Type/Signature.pod6

@@ -228,7 +228,8 @@ the value part of the L<colon-pair|/type/Pair>.
 X<|type constraint,:D>
 X<|type constraint,:U>
 X<|type constraint,:_>
-=head3 Constraining defined and undefined values
+
+=head3 Constraining argument definiteness
 
 Normally, a type constraint only checks whether the value of the parameter is of
 the correct type. Crucially, both I<object instances> and I<type objects> will
@@ -259,7 +260,7 @@ and type objects (C<Int>). Consider the following code:
 Here we really only want to deal with string instances, not type objects. To do
 this, we can use the C<:D> type constraint.  This constraint checks that the
 value passed is an I<object instance>, in a similar fashion to calling its
-L<DEFINITE|/language/mop#DEFINITE> method.
+L<DEFINITE|/language/mop#DEFINITE> (meta)method.
 
 To warm up, let's apply C<:D> to the right-hand side of our humble C<Int> example:
 
@@ -387,6 +388,34 @@ In 6.d language, the default default is the type object without the smiley const
     use v6.d.PREVIEW;
     my Int:D $x .= new: 42; # OUTPUT: «42␤»
 
+A closing remark on terminology: this section is about the use of the type 
+smileys C<:D> and C<:U> to constrain the definiteness of arguments. 
+Occasionally I<definedness> is used as a synonym for I<definiteness>; this may
+be confusing, since the terms have subtly different meanings.
+
+As explained above, I<definiteness> is concerned with the distinction between 
+type objects and object instances. A type object is always indefinite, while an
+object instance is always definite. Whether or not an object is a type 
+object/indefinite or an object instance/definite can be verified using the
+L<DEFINITE|/language/mop#DEFINITE> (meta)method.
+
+I<Definiteness> should be distinghuished from I<definedness>, which is concerned
+with the difference between defined and undefined objects. Whether an object is
+defined or undefined can be verified using the C<.defined>-method, which is 
+implemented in class L<Mu|/type/Mu>. By default a type object is considered 
+undefined, while an object instance is considered defined; that is: C<.defined> 
+returns C<False> on a type object, and C<True> otherwise. But this default 
+behaviour may be overridden by subclasses. An example of a subclass that
+overrides the default C<.defined> behaviour is L<Failure|type/Failure>,
+so that even an instantiated C<Failure> acts as an undefined value:
+
+    my $a = Failure;                # Initialize with type object
+    my $b = Failure.new("foo");     # Initialize with object instance
+    say $a.DEFINITE;                # Output: «False␤» : indefinite type object
+    say $b.DEFINITE;                # Output: «True␤»  : definite object instance
+    say $a.defined;                 # Output: «False␤» : default response
+    say $b.defined;                 # Output: «False␤» : .defined override
+
 =head3 Constraining signatures of C<Callable>s
 
 The signature of a L<Callable> parameter can be constrained by