From zefram@fysh.org

$ ./perl6 -e 'my $a = Mu but True; say $a.WHICH; say $a.perl; my $b = $a.perl.EVAL'
Mu+{<anon>}
Mu+{<anon>}
X​::Multi​::NoMatch exception produced no message
  in block <unit> at EVAL_0​:1
  in block <unit> at -e​:1

The .perl method uses the same text that .WHICH does to distinguish Mu
but True from a mundane Mu. This text parses as Perl code, but is not
correct for .perl's purpose and will not execute. The same happens with
a bunch of other types modified by but.

-zefram

From @AlexDaniel

Still reproducible (2017.11, HEAD(5929887)).

However, I'm wondering if it should be fixed at all. If I get it right, the tickets wants the thing to be roundtrippable, but what about cases like​:

Code​:
my $a = Mu but role { method blah { 42 } };
say $a.blah; say $a.perl

Result​:
42
Mu+{<anon|94497069725968>}

Do we really want it to dump the source? Or am I misunderstanding something?

On 2015-09-18 12​:09​:19, zefram@​fysh.org wrote​:

$ ./perl6 -e 'my $a = Mu but True; say $a.WHICH; say $a.perl; my $b =
$a.perl.EVAL'
Mu+{<anon>}
Mu+{<anon>}
X​::Multi​::NoMatch exception produced no message
in block <unit> at EVAL_0​:1
in block <unit> at -e​:1

The .perl method uses the same text that .WHICH does to distinguish Mu
but True from a mundane Mu. This text parses as Perl code, but is not
correct for .perl's purpose and will not execute. The same happens
with
a bunch of other types modified by but.

-zefram

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

From zefram@fysh.org

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 example,
"(Mu but True).perl" could yield the string "Mu". The bug is that .perl
produces output so broken that .EVAL errors.

-zefram