Notice: forthcoming change to Type::Tiny overloading
One of the features of Type::Tiny that differentiates it from Moose's built-in type constraint system is that it allows stand-alone coercions which can then be mixed with type constraints as required. So if you had a Split coercion which split a multi-line string into an arrayref of lines, you could do something like this:
use MyApp::Types qw( ArrayRef Split ); has lines => ( is => 'ro', isa => ArrayRef + Split, coerce => 1, );
This is one of several features designed to encourage people to combine coercions with type constraints at the point of use, rather than globally. We wouldn't want people adding coercions to the global definition of ArrayRef, because global stuff is bad, remember?
Anyway, the current stable version of Type::Tiny (0.040) is going to be the final one to overload the + operator for this. From now on, you need to use:
use MyApp::Types qw( ArrayRef Split ); has lines => ( is => 'ro', isa => ArrayRef->plus_coercions(Split), coerce => 1, );
The plus_coercions method has existed for quite some time (pre-0.001); it's not new by any means. It's just that the alternative (overloading) is going away. So if you're using that, time to update your code.
Sorry.
Development version 0.041_01 is on CPAN now, and includes this change, so you can test your code with that.
I'm tobyink on CPAN, IRC and PerlMonks. 
Could explain the reasons for this discussion? The overloaded syntax is quite readable, compared to the plus_coercion method (which looks like code in the definition of the attribute, hence a little more scary)
It's never worked especially cleanly because of issues with precedence. Consider:
which Perl parses as:
To make it do what you mean, you need to add parentheses:
Graham Knop wrote some excellent code to get this working for the overloaded
&and|operators.However, extending this to work with coercions is problematic because Type::Tiny supports parameterized coercions; this means that when Graham's overloading shim sees an arrayref, it can't know whether this arrayref represents a type constraint parameterization or a type coercion parameterization.
It's a feature which has never worked quite right; trying to keep it afloat has been preventing me from fixing other problems with the coercion API. That's why it's got to go.
If I can find a way to bring it back at a later date, that would be nice. But if it comes back, it will need to be a better implementation that can work around the precedence issues.