On 13 December 2013 15:18, Paul Johnson <paul@pjcj.net> wrote: > On Fri, Dec 13, 2013 at 02:45:05PM +0100, demerphq wrote: >> On 8 October 2013 22:05, Matthew Horsfall <perlbug-followup@perl.org> wrote: >> > # New Ticket Created by Matthew Horsfall >> > # Please include the string: [perl #120128] >> > # in the subject line of all future correspondence about this issue. >> > # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=120128 > >> > >> > >> > This is a bug report for perl from WolfSage@gmail.com, >> > generated with the help of perlbug 1.39 running under perl 5.10.1. >> > >> > >> > ----------------------------------------------------------------- >> > [Please describe your issue here] >> > >> > I've squashed the two prevous commits related to OP_AND/OP_OR/OP_DOR >> > optimisations and attached it here, and removed the OP_OR/OP_DOR chaining >> > since it was dead wrong. >> > >> > It broke this case: >> > >> > $b = 0; >> > >> > $x = $b // $c || 'cat'; >> > >> > (It caused $x to be 0 instead of 'cat'). >> >> Wow. That that results in "cat" is quite surprising to me. Isn't that >> a precedence bug? > > // and || have the same precedence and are left associative, so we have > > $x = ($b // $c) || 'cat'; > > which is > > $x = 0 || 'cat'; > > which is > > $x = 'cat'; > > So I think that according to the documentation the implementation is > correct. If you are saying the precedence or associativity should be > different then that is another argument, and not one with which I think > I would agree. OK. I think I might have argued that // should have lower precedence than ||, but clearly I am years too late to do that now. :-) Thanks for the explanation. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous