in reply to Re^2: 'return:' instead of 'return'
in thread 'return:' instead of 'return'

I had expected something more like the behaviour from this:
sub fn { sub { 3 } }
Where it's not the 3 that gets returned, rather it's a coderef to an anonymous subroutine.
Are you suggesting you didn't even try to run:
sub fn { return: 3 }
and see what it returns? Printing the return value of fn would have instantly revealed fn had returned '3', and not a code reference.
BTW, is 'return 3;' a statement?
Most certainly. What else could it be? It's not some pretty decorations.
If so, is it then a special exception to the rule 'blocks return the value of the last statement executed'
It's a statement. But it's not a block.
is the value of 'return 3' equal to 3 ?
sub foo {return 3;} print foo(); __END__ 3
So, what do you think?

Replies are listed 'Best First'.
Re^4: 'return:' instead of 'return'
by Boldra (Curate) on Jun 12, 2009 at 10:41 UTC
    Naturally I ran it. Had it returned '1', as I had expected, I would have told my friend "here's a bug, fix it". Since it actually worked, I'll have to go to him and say "here's why I think this is bad style".

    As for your second snippet, I don't know that that answers the question - or maybe the problem is that my question just doesn't make sense. In your example 'return' exits the subroutine and the subroutine then evaluates to '3'. But what does 'return' evaluate to?

    This code:
    perl -wE 'sub fn{ return 3 and die("bury me where this arrow lands") } + say fn'
    also prints 3, but I assume the die is not executed because the subroutine has exited, not because the 'return' did not evaluate to true. I can't think of an example which would clearly show the difference (between what return evaluates to and what the subroutine evaluates to) maybe because there really isn't a difference?


    - Boldra
      Yes, there is no difference and why should there be any? return exists because you might want to leave the subroutine in the middle instead of at the end or leave from more than one location in the subroutine. And it exists to make it explicit what value is returned, it makes the program easier to read and less errorprone. If you have Damian Conways book 'Perl Best Pratices' at hand, it gives an example why explicit returning is better style, in section 'Implicit Returns'
        Yes, there is no difference and why should there be any?
        I don't know, maybe you could use it to force other Best Practices, eg:
        sub close_all { my $self = shift; $success = 1; foreach( $self->files ) { $success = $_->close && $success } return $success or die("You must check the return value of close_all +"); }
        Where return would only evaluate to true if the calling program read the value of the call.

        (Yes, I know you can already do this with the cpan module Want).


        - Boldra
      But what does 'return' evaluate to?
      When in doubt, don't consult Perlmonks. Read the documentation. Not only do you get your answer faster, it isn't buried between posts that don't answer your questions. It also doesn't require other people to read the documentation for you.
      $ perldoc -f return return EXPR return Returns from a subroutine, "eval", or "do FILE" with th +e value given in EXPR. Evaluation of EXPR may be in list, scal +ar, or void context, depending on how the return value will be + used, and the context may vary from one execution to the next + (see "wantarray"). If no EXPR is given, returns an empty li +st in list context, the undefined value in scalar context, an +d (of course) nothing at all in a void context. (Note that in the absence of an explicit "return", a subroutine, eval, or do FILE will automatically return +the value of the last expression evaluated.)
        This still doesn't explain what 'return 3' evaluates to, just what it returns. I'm very sorry if you feel reading my posts was a waste of your time, JavaFan, I don't feel that reading yours was a waste of my time, so I thank you for your patience.


        - Boldra