diff --git a/src/multi-dispatch.pod b/src/multi-dispatch.pod
index 1b406bb..d0ce9c4 100644
--- a/src/multi-dispatch.pod
+++ b/src/multi-dispatch.pod
@@ -33,8 +33,8 @@ can be found at L.
}
multi to-json($d where undef) { 'null' }
- multi to-json($s) {
- die "Can't serialize an object of type " ~ $s.WHAT.perl
+ multi to-json($d) {
+ die "Can't serialize an object of type " ~ $d.WHAT.perl
}
@@ -103,3 +103,31 @@ line with C prints a higher number than the first.
(TODO: insert side note "Don't do that at home, kids! Type checks with side
effects are a B bad idea in real world code")
+
+Back to the JSON example, there's one candidate not yet explained.
+
+ multi to-json($d) {
+ die "Can't serialize an object of type " ~ $d.WHAT.perl
+ }
+
+This has not explicit types or constraint on its parameter at all, so it
+defaults to C - and thus matches any object we might pass to it. The code
+just complains that it doesn't know what to do with the argument, because JSON
+is just defined for some basic structures.
+
+That might look simple at first, but if you look closer you find that it
+doesn't just match for objects of all type for which no other candidate is
+defined - it matches for I objects. Including C, C, C and
+so on. So for a call like C there are two matching candidates -
+C and C.
+
+If you try it out, you'll find that the dispatcher (which is the part of the
+compiler that decides which candidate to call) still calls the C
+candidate.
+
+The explanation is that since C is a type that conforms to C, it is
+considered a tighter match for an integer. More generally speaking if you have
+two types C and C, and C conforms to C (or C is the Perl 6
+programmer says), then an object which conforsm to C does so more
+tightly than to C. And in the case of a multi dispatch the tightest match
+always wins.