Yeah, you're thinking along the same lines as I was. Unfortunately, there
needs to be consensus about whether this behavior should be changed before
it can be implemented -- any idea how to make that come about?
Deven
On Sun, 21 Jan 2001, David L. Nicol wrote:
> "Deven T. Corzine" wrote:
> >
"Deven T. Corzine" wrote:
>
> On Sat, 23 Dec 2000, Graham Barr wrote:
>
> > This has been discussed on p5p many many times. And many times
> > I have agreed with what you wrote. However one thing you did not mention,
> > but does need to be considered is
> >
> > func($x{1}{2}{3})
> >
> > at th
On Sat, 23 Dec 2000, Graham Barr wrote:
> This has been discussed on p5p many many times. And many times
> I have agreed with what you wrote. However one thing you did not mention,
> but does need to be considered is
>
> func($x{1}{2}{3})
>
> at this point you do not know if this is a read o
This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is
func($x{1}{2}{3})
at this point you do not know if this is a read or write access as
the sub could do $_[0] = 'fred'. If th
Can the autovivication behavior be changed slightly for Perl 6?
Specificly, can we suppress autovivication in read-only circumstances, and
evaluate the expression as "undef" immediately instead of autovivicating
empty data structures that didn't exist before?
The current behavior in Perl 5 is i
