Thanks for doing that experiment. Not sure why the code breaks. But yeah on
second thought it was a bad idea. If something accepts a Mu in its
signature it should probably be given a Mu even with ~~.
LL
On Sat, Apr 8, 2017 at 12:58 PM Zoffix Znet via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Fri, 07 Apr 2017 19:09:55 -0700, lloyd.fo...@gmail.com wrote:
> > IMO any() junctions should propagate exceptions regardless of whether
> one of its other values succeeded
>
> Well, they do. The exception gets thrown. It just aborts all of the
> results. In a superimposition of multiple universes calculating $foo == 42,
> a crash in one universe crashes all of them :|
>
Would be interesting to see a Junctioned result in $! though :)
>
> > I think it's generally considered a bug anytime ~~ throws an exception
> because of invalid LHS
>
> Yes. Please report anything that explodes in smartmatch. We recentlish
> fixed Str ~~ Numeric smartmatch exploding, so actually anyone on latest
> Rakudo Star would get an explosion in `"foo" ~~ 42`
>
> > I guess bare blocks don't autothread because $_ is Mu
>
> That's correct. Only subs and methods default to Any. Variables,
> attributes, and block's params default to Mu type constraint. Asking for a
> `Mu` is a way to avoid Junctional autothreading in routines. You'll notice
> a Junction is a Mu, but unlike most Perl 6 classes, is not an Any.
>
> > thought ACCEPTS on Code would autothread but it seems it's also Mu (could
> > we change this?).
>
> Changing it breaks 5 stresstests. We also smartmatch in `when` blocks and
> `where` constraints, so the impact would be far-reaching. Making ACCEPTS
> not accept a Mu breaks this code for example; it no longer prints the
> string:
>
> $_ = 42|42; when *.so { say "there"}
>
