Re^6: reset particular variable

(I've seen Marshall's updated post, so this post is a bit redundant; but what the heck, I've already done the work, may as well cash the check.)

Based on the example code below, I'm willing to go out on a limb and say there is no difference between the behavior of the return; and return (); statements in list or in scalar context; that is, although they behave differently in list versus scalar context, they behave differently in exactly the same way. (The example code uses the $x = 1 + scalar @_; business to try to make absolutely sure that the 'statement evaluating to true' is not just optimized away by the compiler.)

>perl -wMstrict -le
"my $x;
 sub Sbr { $x = 1 + scalar @_;  return    }
 sub Sel { $x = 1 + scalar @_;  return () }
 my ($s, @ra);
 $s = Sbr();
 print 'scalar bare return ', defined $s ? '' : 'UN', 'defined';
 print qq{scalar context bare return: '$s'};
 $s = Sel();
 print 'scalar empty list ', defined $s ? '' : 'UN', 'defined';
 print qq{scalar context empty list: '$s'};
 @ra = Sbr();
 print qq{list context bare return: (@ra)};
 @ra = Sel();
 print qq{list context empty list: (@ra)};
"
scalar bare return UNdefined
Use of uninitialized value in concatenation (.) or string at ...
scalar context bare return: ''
scalar empty list UNdefined
Use of uninitialized value in concatenation (.) or string at ...
scalar context empty list: ''
list context bare return: ()
list context empty list: ()
[download]

So I guess it comes down to the questions: Is there any difference in the behavior of the return; and return(); and return (); statements that does not arise from a context difference? Do they behave exactly the same way in list context? Do they behave exactly the same way in scalar context? My answers would be: no; yes; yes.

(And BTW: I completely agree with you about the importance of returning an empty list in, e.g., a map statement in which you wish to truncate the output list.)

Comment on Re^6: reset particular variable Select or Download Code

Replies are listed 'Best First'.
Re^7: reset particular variable by Marshall (Canon) on Aug 21, 2009 at 23:31 UTC
I suspect that you are right. I will have to "noodle on this a bit" to completely convince myself, but I suspect that it is true. As often happens in these threads, we have gone a long way from the original question about "reset"! I believe that there is consensus that package scoped variables and reset is not the best way although this is part of the language. I was surprised, but this IS truly a language construct. However, just because "it works", doesn't mean that it is a good idea - smaller scoped lexical variables is the "right" idea. Then we got onto map{} and how to suppress an "undef" value which is also a good idea. Now we are onto something that hasn't come up in the last few years of my coding. Almost all my subs{} return something and that result is expected and used or I consider this a coding error. Subs that don't return things are signal handlers or subs that modify a reference that is passed in. Basically I don't try to check return values from subs that aren't expected to return anything as a lvalue and I don't have much experience checking for this situation in a normal sub. I figure that until proved otherwise AnomalousMonk has it right! Great work! Thanks!	[reply]
Re^8: reset particular variable by Anonymous Monk on Aug 22, 2009 at 00:55 UTC
I believe that there is consensus that package scoped variables and reset is not the best way although this is part of the language. reset is a holdover from perl4, no-one uses it anymore	[reply]