On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote: > By distinguishing a parameter that *requires* a particular type, from > a parameter that *ensures* a particular type (by coercion if > necessary). I've suggested that using C<is copy> semantics should > indicate "make whatever I'm actually given into one of these, if you > can", whereas reference semantics say "this must already be one of > these" (by their very nature, since an aliased parameter *is* the > argument).
It looks like a lot of people is going to use "is copy" a lot. Correct me if I am wrong, but I see the default "is constant" trait largely as a speed optimization. Would not it be more correct from the point of view of good Huffman coding, that "is copy" is made the default, and let the module authors and large project implementors to bother with "is constant" when they deem it necessary? After all, this will be a small added burden for folks who go the "type and trait everything" route. An extra bonus of making "is copy" the default would be the ability to modify a parameter locally (Huffman coding again here for short program writers). =Anton.
