Author: audreyt Date: Wed Apr 2 09:13:06 2008 New Revision: 14533 Modified: doc/trunk/design/syn/S09.pod
Log: * S09/Autovivification: Change the wording "assignment implicitly binds a copy" to "assignment is treated the same way as binding to a copy container", because assignment and binding are two orthogonal concepts. Reported by: John M. Dlugosz Modified: doc/trunk/design/syn/S09.pod ============================================================================== --- doc/trunk/design/syn/S09.pod (original) +++ doc/trunk/design/syn/S09.pod Wed Apr 2 09:13:06 2008 @@ -14,7 +14,7 @@ Date: 13 Sep 2004 Last Modified: 2 Apr 2008 Number: 9 - Version: 25 + Version: 26 =head1 Overview @@ -1168,10 +1168,14 @@ Autovivification will only happen if the vivifiable path is bound to a read-write container. Value extraction (that is, binding to a readonly -or copy container) does not autovivify. (Note that assignment implicitly -binds a copy, so it does not autovivify its right side.) Any mention of -an expression within a C<Capture> delays the autovivification decision -to binding time. (Binding to a "ref" parameter also defers the decision.) +or copy container) does not autovivify. + +Note that assignment is treated the same way as binding to a copy container, +so it does not autovivify its right side either. + +Any mention of an expression within a C<Capture> delays the autovivification +decision to binding time. (Binding to a "ref" parameter also defers the +decision.) This is as opposed to Perl 5, where autovivification could happen unintentionally, even when the code looks like a non-destructive test:
