Re: Situation where warning "Found = in conditional, should be" seems obsolete

Background: Short circuit and and or are semantically like if and unless in Perl, IIRC it's even the same op code.

Personally I tend to avoid this C syntax outside one liners, where readability and maintenance are no issues.

Now this warning is intended for conditionals.

So if you don't like to straighten the syntax, you are free to disable this warning.

update

Especially chaining both operators without parens makes me second guessing precedence

$_ % 2 or $has_even = 1 and last

I don't wanna puzzle over such code.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

Comment on Re: Situation where warning "Found = in conditional, should be" seems obsolete Download Code

Replies are listed 'Best First'.
Re^2: Situation where warning "Found = in conditional, should be" seems obsolete by LanX (Saint) on Feb 06, 2021 at 18:07 UTC
`perlop` is clear that `and` has higher precedence than `or` and this can be checked with B::Deparse and `-p` option `$_ % 2 or ( $has_even = 1 and last )` Like others already implied does `$has_even = 1 and last` not make much sense, since the assignment at LHS is always true. Furthermore is this a quite pathological case, because the part with the code-branch with higher precedence is never executed. compare `DB<215> p 0 or 1 and 0 0 DB<216> p (0 or 1) and 0 1 DB<217>` [download] update `DB<233> p 0 or 1 and die "never" 0 DB<234> p 0 or (1 and die "never") 0 DB<235> p (0 or 1) and die "never" 1never at (eval 265)[c:/Perl_524/lib/perl5db.pl:737] line 2. DB<236>` [download] Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Situation where warning "Found = in conditional, should be" seems obsolete
by LanX (Saint) on Feb 06, 2021 at 18:07 UTC

perlop

and

or

B::Deparse

-p

$_ % 2 or ( $has_even = 1 and last )

Like others already implied does $has_even = 1 and last not make much sense, since the assignment at LHS is always true.

Furthermore is this a quite pathological case, because the part with the code-branch with higher precedence is never executed.

compare

  DB<215> p 0 or 1 and 0
0
  DB<216> p (0 or 1) and 0
1
  DB<217>
[download]

update

  DB<233> p 0 or 1 and die "never"
0
  DB<234> p 0 or (1 and die "never")
0
  DB<235> p (0 or 1) and die "never"
1never at (eval 265)[c:/Perl_524/lib/perl5db.pl:737] line 2.

  DB<236>
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

[reply]
[d/l]
[select]