S29 Q: Rules for boxed types

[Aaron Sherman]

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?

[Rod Adams]

Aaron Sherman wrote:

>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).
>
>

My thoughts on writing it were:

The boxed version is the specification, in that the language must
support them. Think about using a SubType somewhere, and you see why.
However, I also fully expected implementations to add an easy
optimization of including unboxed equivalents and letting MMD sort it out.

-- Rod Adams

[Aaron Sherman]

On Sun, 2005-05-15 at 13:33 -0500, Rod Adams wrote:
> Aaron Sherman wrote:
>
> >In reviewing S29 as it stands now, I see that many builtins both receive
> >and return boxed basic types.

> My thoughts on writing it were:

>
> The boxed version is the specification, in that the language must
> support them. Think about using a SubType somewhere, and you see why.

Ok, that makes sense.

> However, I also fully expected implementations to add an easy
> optimization of including unboxed equivalents and letting MMD sort it out.

And this makes sense too. Thanks Rod!