On Thu, Mar 13, 2003 at 10:52:04PM +0100, Anton Berezin wrote: : 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).
Well, at minimum there could certainly be a "use sig copy" pragma or some such. But I don't think "is copy" will be used all that much if we set up "is constant" with the right semantics in the first place, which is that it can do a copy of basic types if it feels like it. It's only "is rw" or "is ref" that really require reference semantics, and then we're talking proxies if we want any coercion. Larry
