From: Ben Tilly Date: Thu, 13 Dec 2001 08:57:38 +0000 (-0500) Subject: Clarifying the documentation of goto X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=1b6921cb418a43a6118f8bbad3bcf281bcd55c17;p=p5sagit%2Fp5-mst-13.2.git Clarifying the documentation of goto Message-ID: <3C18BD8B@operamail.com> p4raw-id: //depot/perl@13670 --- diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod index 6d79b7a..047e7f6 100644 --- a/pod/perlfunc.pod +++ b/pod/perlfunc.pod @@ -2083,6 +2083,9 @@ It can be used to go almost anywhere else within the dynamic scope, including out of subroutines, but it's usually better to use some other construct such as C or C. The author of Perl has never felt the need to use this form of C (in Perl, that is--C is another matter). +(The difference being that C does not offer named loops combined with +loop control. Perl does, and this replaces most structured uses of C +in other languages.) The C form expects a label name, whose scope will be resolved dynamically. This allows for computed Cs per FORTRAN, but isn't @@ -2090,13 +2093,14 @@ necessarily recommended if you're optimizing for maintainability: goto ("FOO", "BAR", "GLARCH")[$i]; -The C form is quite different from the other forms of C. -In fact, it isn't a goto in the normal sense at all, and doesn't have -the stigma associated with other gotos. Instead, it -substitutes a call to the named subroutine for the currently running -subroutine. This is used by C subroutines that wish to load -another subroutine and then pretend that the other subroutine had been -called in the first place (except that any modifications to C<@_> +The C form is quite different from the other forms of +C. In fact, it isn't a goto in the normal sense at all, and +doesn't have the stigma associated with other gotos. Instead, it +exits the current subroutine (losing any changes set by local()) and +immediately calls in its place the named subroutine using the current +value of @_. This is used by C subroutines that wish to +load another subroutine and then pretend that the other subroutine had +been called in the first place (except that any modifications to C<@_> in the current subroutine are propagated to the other subroutine.) After the C, not even C will be able to tell that this routine was called first.