In reviewing S29 as it stands now, I see that many builtins both receive and return boxed basic types. This seems like potentially spurious overhead in some situations, while essential in others, so I wanted to work out a set of rules for when boxed vs. unboxed types would be used in core routines (given that all rules will have exceptions).
Here's my first pass for review, using the standard meaning of "must" and "should" from the RFC world. * By default, basic type parameters should be unboxed * "is rw" parameters must be boxed * Return values should not be boxed by default This means: sub lc(str ?$string = $CALLER::_) returns str {...} sub chomp(Str ?$string is rw = $CALLER::_) returns int {...} This all assumes that it is far more trivial to extract an unboxed basic type from a boxed basic type (which requires accessing encapsulated data) than it is to go the other way (which requries construction). Thoughts?