From @masak

<hoelzro> when determining the longest literal prefix for a rule, I
see that | alternation variants can extend the literal prefix. Does
the same apply for ||?
<masak> no.
<hoelzro> thanks masak
<jnthn> Yeah, hitting a sequential alternation marks the end of the
declarative prefix.
<jnthn> (just checked that's exactly what happens in the code)
<hoelzro> I saw the behavior, just checking to see that it made sense
spec-wise =)
<jnthn> aye, I believe so
<FROGGS> 'think so too fwiw
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' || 'doof')/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»
<TimToady> hmm, STD would've picked 'food' there
<FROGGS> ò.ó
<TimToady> it counts the first part of the || as declarative
<jnthn> TimToady​: Declarative but optional, I presume?
<TimToady> it counts the 'food' as part of LTM, iirc
<TimToady> on the assumption that most || are just error throws
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' <!> || 'doof')/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»
<masak> TimToady​: well, does that have any support in S05? otherwise
S05 should probably mention that...
<TimToady> masak​: depends on how you read it...it says that LTM is
terminated by a ||
<TimToady> masak​: actually, it's explicitly required at S05​:2885
<TimToady> so this is a bug, by that
* masak submits rakudobug
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' <!> || die "Should die here")/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»

From @jnthn

On Mon Jul 13 13​:19​:15 2015, masak wrote​:

<hoelzro> when determining the longest literal prefix for a rule, I
see that | alternation variants can extend the literal prefix. Does
the same apply for ||?
<masak> no.
<hoelzro> thanks masak
<jnthn> Yeah, hitting a sequential alternation marks the end of the
declarative prefix.
<jnthn> (just checked that's exactly what happens in the code)
<hoelzro> I saw the behavior, just checking to see that it made sense
spec-wise =)
<jnthn> aye, I believe so
<FROGGS> 'think so too fwiw
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' || 'doof')/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»
<TimToady> hmm, STD would've picked 'food' there
<FROGGS> ò.ó
<TimToady> it counts the first part of the || as declarative
<jnthn> TimToady​: Declarative but optional, I presume?
<TimToady> it counts the 'food' as part of LTM, iirc
<TimToady> on the assumption that most || are just error throws
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' <!> || 'doof')/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»
<masak> TimToady​: well, does that have any support in S05? otherwise
S05 should probably mention that...
<TimToady> masak​: depends on how you read it...it says that LTM is
terminated by a ||
<TimToady> masak​: actually, it's explicitly required at S05​:2885
<TimToady> so this is a bug, by that
* masak submits rakudobug
<TimToady> m​: say 'food' ~~ / 'foo' | ('food' <!> || die "Should die here")/
<camelia> rakudo-moar 533d1a​: OUTPUT«｢foo｣␤»

Fixed, and tested in S05-metasyntax/longest-alternative.t.

The RT System itself - Status changed from 'new' to 'open'

@jnthn - Status changed from 'open' to 'resolved'