Front page | perl.perl5.porters |
Postings from November 2015
> Please stop sending your tutorial questions to perlbug.
This is not a question. This is "Feature Request: get more benefit from ||, &&"
I understand what is coming on in supplied examples.
> This is a venue for reporting bugs in the perl core;
This is not bug report this is wishlist. Please notice the serverity flag:
> Flags:
> severity=wishlist
It is maybe I try to describe problem of @x = @y || @z too detailed and had failed.
(forget I have said before)
I will try make it short
The doc says that Perl really do this: @x = scalar(@y) || @z;
*But it is ugly to get scalar result when we want the list* ( the behaviour of || in this case is ugly a bit )
There is no any reason to not return list ( @y ) in this case (except for backward compatibility. but in any case
we may not allow this feature by default in future versions of perl)
When we return list while list is required in this case
we will have these benefits:
@x ||= qw/ s o m e d e f a u l t s /; # ('s','o'...'s') if @x is empty
@x = $str =~ /^(\d)(\d)(\d)$/ || (); # (7,5,3) if $str eq '753', NOT (3)
@x = fn_this() || fn_that(); # faster: only one call to fn_this
@x = fn_this() ? fn_this() : fn_that() ; # slower: fn_this called twice
2Abigail
>You aren't clear what "it" in "it is list" refers to. The statement has
>several sub expressions, some in scalar context, others in list context.
Yes. I Mean that left operand of || is subexpression and
1. it should be evaluated in *list context* because || is evaluated in list context
2. The *evaluated result* can be forced into scalar for internal requirements of ||,
but || should return the *evaluated result* not scalar(result)
And this is behaviour is more clear than that is currently implemented.
Thread Next