Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
>tickets wants the thing to be roundtrippable,
To preserve the "but" qualifier would be the best outcome, but that's
not essential. I'd consider the bug fixed if .perl produced code lacking
the "but" but accurately representing everything else. For
Brian S. Julin via RT wrote:
> it would be OK for there to be some tiny chance
>of a collision between two WHICH.Str's as long as the actual WHICHs
>do not collide.
One could make that distinction, but then the .Str of the .WHICH would
not fulfill the purposes for which .WHICH
Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.
Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.
-zefram
Brian S. Julin via RT wrote:
>It is that Nil is also semantically special as a RHS of an assignment
>or as a parameter.
...
>This is mentioned in S02.
Some of the specialness mentioned in S02 doesn't happen, such as .ACCEPTS
returning Nil, and getting the default value of an optional parameter.
Th
With commit 167a0edf the behaviour of Set.WHICH has changed in a
manner relevant to this ticket. The .WHICHes of the elements are no
longer concatenated with space separators, so spaces no longer confuse
Set.WHICH as they used to. The element .WHICHes are now concatenated
with '\0' separators, s
Brian S. Julin via RT wrote:
>For example "Foo^".."Bar" and "Foo"^.."Bar" would put out the same WHICH.
Yes, and that's a bigger problem. In general Rakudo's .WHICH methods
suffer this sort of problem when incorporating the .WHICH values of
subobjects. See [perl #128943] (Set, and in which I ske
Zoffix Znet via RT wrote:
>For record, all three of the problematic ones now throw. Is that the
>desired behaviour?
Not the desired behaviour, no. It's a massive improvement over giving
the wrong answer, and arguably fixes the bug qua bug, but it's still
less than awesome. It would be easy (and
