On Sat, Nov 09, 2002 at 11:22:45PM -0800, Brent Dax wrote: : I think that, if Perl can determine the type with virtually no : ambiguity, it should autovivify. In this case, since we know they : wanted an array (they used the @ explicitly), we'll autovivify an array. : (I say "virtually no" because one could make the argument that you don't : know if we wanted a standard array or a typed one.)
I would not tie autovivification to typing. Autovivification only makes sense when there's an existing value you need to construct a location for, so it really only makes sense in the lvalue of an assignment, (or a parameter that is rw because it's going to be assigned to.) Much of the utility of autovivification goes away if we require typing. And really, the autovivification bugs of Perl 5 have to do with not distinguishing referential context from lvalue context. (And with ops that aren't smart enough to turn an undef ref into an undef value in an *rvalue* context.) So I think Perl 6 should autovivify an untyped array if assigned to. I'm not terribly interested in turning Perl 6 into a language that only DWIMs if you type your variables. On the other side, one might argue that autovivification of untyped arrays could be disallowed under "use strict autoviv" or some such. At some point we'll need to determine how many settings there are on the stricture "knob" for Perl 6, and whether there's any good mechanism for adding new strictures without breaking old code. It seems a little stupid to have to specify which version of strict you're using... Larry
