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?
