The Perl 6 student begins: sub add(\number1, \number2) { number1 + number2 } If you call `add` with simple numbers it works: say add(1, 2) # 3 Other

The Perl 6 student begins: sub add(\number1, \number2) { number1 + number2 } If you call `add` with simple numbers it works: say add(1, 2) # 3 Other types of number too: say add(0.1, 0.2) == 0.3 # True It works even for newbie definitions of "number": say add('0.1', '0.2') == '0.3' # True A sufficiently determined newbie can of course break `add`: say add('foo', 'bar') == 'waldo' The program stops with a suitable error message ("Cannot convert string to number ..."). ---- The student moves on to a more advanced course... ---- Type annotations are introduced: sub add(Numeric \number1, Numeric \number2) { number1 + number2 } Everything still works as expected: say add(1, 2) # 3 But we get better error checking: say add('foo', 'bar') == 'waldo' This generates a compile-time type-checking error ("Calling add(Str, Str) will never work with declared signature (Numeric \int1, Numeric \int2)"). So, reason 1 for using types: get type-checking that catches errors at compile-time. You can use native types for closer-to-the-metal speed (compact representations, no automatic overflow checking, etc.): sub add(num64 \number1, num64 \number2) { number1 + number2 } `num64` corresponds to C's double float datatype representation. This sub will likely outperform the versions of `add` that do not have natively typed parameters. A third reason for explicit types is to take advantage of C interop: use NativeCall; sub add(int32, int32) returns int32 is native("calculator") { * } If you've got a local C library (called "libcalculator.so" or somesuch) then this: say add(1,2) will call the function with the symbol name `add` in that library. And so on.