<[Coke]> rant: old tickets with "maybe" or "either std or rakudo is wrong"
<masak> [Coke]: if I'm to blame for "either std or rakudo is wrong" tickets,
send them to me and I'll take action on them.
<masak> I'm pretty sure I don't file "maybe" tickets :)
<[Coke]> masak: RT #77334
<synopsebot> Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=77334
* masak looks
<[Coke]> that maybe ticket is from 4 years ago.
<masak> oh, we talked about that one the other day.
<masak> the question we should ask on that one is "what use case are we making
impossible by having `for` loops decontainerize?"
<masak> actually, two more questions.
<masak> "which way is least surprize?" (pretty sure it's doing the decont)
<masak> "which way shoots us in the fewest amount of feet wrt performance?"
(pretty sure it's the decont)
<masak> in other words, if we can't think of a use case for Q1, then there's no
"maybe" there.
<masak> [Coke]: good enough? :)
* masak adds this to the ticket
<[Coke]> please update the subject to indicate the choice.
<masak> [Coke]: well, we haven't quite failed to think of a use case yet...
<[Coke]> so it is still a maybe? arglebargle.
<masak> m: sub foo { my $s; (+($s += $_) for 1..3) }; say foo() # [Coke]:
here's the result if we decont.
<camelia> rakudo-moar 9a6644: OUTPUT«1 3 6»
<masak> [Coke]: do you agree that it's a less surprising result?
<[Coke]> masak: surprising or no, I want tickets of the form "this code
generates result A when it should generate result B". not "we're not sure
what's the right answer here..."
<[Coke]> because that kind of ticket stays open for 4 years.
<masak> *nod*
<masak> ok, I'll remove the "maybe", simply because I haven't seen and can't
think of a use case that's more important than not letting [Coke] down.
<masak> anyone from the future who knows of such a use case, take note: I
consider uprooting my decision to be valid to the extent there's a use case to
motivate it.
<masak> that may include but is not limited to someone who tries to implement
this and notices that the correct implementation fails some (hard to dispute)
previously passing spectest.
