perl5i is also about getting the defaults righter.
Make Perl 5 DWIM better,
without having to load a dozen Perl modules.

perl5i was originally conceived after Schwern had a conversation with a Ruby programmer who had a job writing Perl.
He was listening to their complaints about Perl and providing better solutions where possible.
What he found was a lot of the solutions were "go get this module from CPAN" or "turn on this pragma".
use strict,
use warnings,
use autodie,
use autobox,
use List::Util,
use DateTime.

Not only does this cause you to litter your code with a dozen use statements,
it also requires tribal knowledge not neccessarily available to the new programmer.
To use Perl 5 well requires an experienced Perl programmer looking over your shoulder,
giving you advice.

For the experienced Perl 5 programmer,
using perl5i means writing less boilerplate code.
It means not having to decide between doing it the right way and doing it the convenient way.
For example,
you probably should be using a proper exception handling module,
but which one?
And then you have to get it and remember to load it.
perl5i gives you try and catch that are always there,
there's no excuse not to do it right.

perl5i is in some ways a release valve for the frustration surrounding Perl 5 development,
particularly with regard to Perl 5's conservative backwards compatibility requirements.
Patching Perl 5 is also out of the league of most Perl programmers (and a lot of C programmers).
Can't get a feature into Perl 5?
Put it in perl5i.

Since it has a liberal compatibility policy,
perl5i serves as a testing ground for new features.
It will let the community try out new concepts in the wild and see how it works out.
For example,
autoboxing has been available for years but was rejected from incusion in Perl 5 in part because Perl 5 programmers do not grok the benefits of everything being an object.

Yes,
the API is stable and its well tested.
Its effects are mostly lexical and incompatibilities are with obscure "features" that you're probably not using.

Rather than reinventing the wheel,
perl5i is mostly a wrapper around stable,
well understood CPAN modules.
It avoids unstable magic.

perl5i's interface is NOT compatible between major versions,
but fear not!
perl5i has an intentional backwards incompatibility plan so that code written for one version will continue to work even after you upgrade.
Please read "Using perl5i" in perl5i for details.

perl5i tries to make you only pay for what you use.
It delays loading most modules to keep startup time reasonable.

While we've been watching perl5i's weight,
serious performance optimization has not begun.
Interface and correctness take priority.

Autoboxed methods carry a run-time performance penalty similar to a normal method call.
In general,
because perl5i has to wrap much of Perl 5 it will run slower.
Whether this actually effects the performance of your app should be determined by profiling your entire app and not just benchmarking individual operators.

perl5i's true performance comes out in helping the programmer write code faster and more consistently with less hand written code for common tasks.
In some cases we've discovered perl5i works faster than the equivalent hand coded solution because perl5i can take advantage of very clever CPAN modules written in XS.
Of course,
you can do that without perl5i but we've done the research for you.

perl5i is not backwards compatible across major versions. This is why when you use perl5i you use a major version such as use perl5i::2. This guarantees that code you write will continue to work even after perl5i has changed.

When depending on perl5i, depend on the specific major version. That is, depend on perl5i::2 and not perl5i. This is because older versions will eventually be spun out into their own separate distributions to avoid cluttering the main dist. If you depend on perl5i::2 then the CPAN shell will always be able to find it.

Wonderful! Let us know. The best way is to create an issue in the issue tracker at http://github.com/schwern/perl5i/issues. Think of it less as an issue tracker and more of a web forum with great tagging.

Or you can send mail to perl5i@googlegroups.com.

What is particularly useful to perl5i is to hear about problems you'd like solved. Tell us about a simple problem that you had to write too much code to solve, or load too many modules, or that had too many caveats.

In addition, simply using Moose doesn't buy you much. Like perl5i, it is one line to fix much of Perl's OO woes. But even Moose needs fixing. What we would really like is to be able to conditionally use MooseX::Declare which fixes Perl's OO syntax as well as provides some better Moose defaults. But that has the double whammy of using Devel::Declare and Moose.

That's not a question. Eventually, perl5i will look into a bundling solution to ease the dependency hell it's rapidly descending into. In general we've favored using a CPAN module over writing it ourselves so maintenance can be distributed.

We monitor the health of our dependencies and try to pick ones which are solid or fix those which fail too often.