This is NOT a type system for Perl 5. These are type constraints, and they are not used by Moose unless you tell it to. No type inference is performed, expressions are not typed, etc. etc. etc.

A type constraint is at heart a small "check if a value is valid" function. A constraint can be associated with an attribute. This simplifies parameter validation, and makes your code clearer to read, because you can refer to constraints by name.

Since the types created by this module are global, it is suggested that you namespace your types just as you would namespace your modules. So instead of creating a Color type for your My::Graphics module, you would call the type My::Graphics::Types::Color instead.

This module can play nicely with other constraint modules with some slight tweaking. The where clause in types is expected to be a CODE reference which checks its first argument and returns a boolean. Since most constraint modules work in a similar way, it should be simple to adapt them to work with Moose.

If no message is specified, a default message will be used, which indicates which type constraint was being used and what value failed. If Devel::PartialDump (version 0.14 or higher) is installed, it will be used to display the invalid value, otherwise it will just be printed as is.

This will create a basic subtype for a given set of strings. The resulting constraint will be a subtype of Str and will match any of the items in \@values. It is case sensitive. See the "SYNOPSIS" for a simple example.

NOTE: This is not a true proper enum type, it is simply a convenient constraint builder.

It takes a subroutine reference as an argument. When the type constraint is tested, the reference is run with the value to be tested in $_. This reference should return true or false to indicate whether or not the constraint check passed.

It takes a subroutine reference as an argument. When the type constraint fails, then the code block is run with the value provided in $_. This reference should return a string, which will be used in the text of the exception thrown.

This can be used to define a "hand optimized" inlinable version of your type constraint.

You provide a subroutine which will be called as a method on a Moose::Meta::TypeConstraint object. It will receive a single parameter, the name of the variable to check, typically something like "$_" or "$_[0]".

The subroutine should return a code string suitable for inlining. You can assume that the check will be wrapped in parentheses when it is inlined.

The inlined code should include any checks that your type's parent types do. If your parent type constraint defines its own inlining, you can simply use that to avoid repeating code. For example, here is the inlining code for the Value type, which is a subtype of Defined:

This is a utility function for doing simple type based dispatching similar to match/case in OCaml and case/of in Haskell. It is not as featureful as those languages, nor does not it support any kind of automatic destructuring bind. Here is a simple Perl pretty printer dispatching over the core Moose types.

The matcher is done by mapping a $type to an \&action. The $type can be either a string type or a Moose::Meta::TypeConstraint object, and \&action is a subroutine reference. This function will dispatch on the first match for $value. It is possible to have a catch-all by providing an additional subroutine reference as the final argument to match_on_type.

You can define coercions for type constraints, which allow you to automatically transform values to something valid for the type constraint. If you ask your accessor to coerce by adding the option coerce => 1, then Moose will run the type-coercion code first, followed by the type constraint check. This feature should be used carefully as it is very powerful and could easily take off a limb if you are not careful.