You're arguing for a solution which requires that programmers remember to put their "use" statements in the correct order lest things break, right?

Quote:

Of course, this means that the user needs to 'use' modules that import non-traits before 'use'ing Class::Trait.

So, "yes".

So if a programmer forgets and slips in a "use" statement after using "Class::Trait", the code mysteriously breaks in a rather hard to debug way.

You wanted something implicit and magical. This leads to what you've described above. Make it explicit if you prefer. I, having drunk the Perl kool-aid, would probably allow all three ways to use it:

1. All subroutines are methods to be 'exported'
2. All subroutines that were not 'imported' are methods to be 'exported'
3. Explicitly list which subroutines to 'export'
4. Explicitly list which subroutines to not 'export'
5. Explicitly list a dividing line between the two sets
6. A fanatical devotion to the pope

All of these have their draw-backs. And most of them have several ways that you could implement them.

For example, sub :trait foo { ... } is one way to explicitly list which subroutines to 'export'.

And the way Class::Trait already works involves setting options via use so this all fits together nicely and makes the solution I proposed not so implicit and so no more magical and hard to debug than any of the others (which all involve some action-at-a-distance):

package Limit::Traits;

use Class::Traits 'base';

use POSIX ':limits_h';            # These aren't trait methods
sub _internal;
use Class::Traits 'export_below'; # or 'export_all' or ...
use Trait::Builder qw( ... );     # These are trait methods

# These, are trait methods:
sub foo { ... }
sub bar { ... }
sub _internal { ... }    # Not a trait method
[download]

Pick your poison. Or let your users pick theirs.