with is not tested with Junction

[gfldex]

The current behaviour was changed/implemented without further discussion because of rt.perl.org#130099. This made the following DWIM:

with $a & $b {;}

However, it was not tested in S04-statements/with.t and I believe it should have.

It futher created the following surprise:

    my \a = (42 & 42).defined;
    dd a; # Bool::True
    my \b = (42 & 42).Str;
    dd b; # all("42", "42")

If this issue is closed with an addition to with.t, please file an issue in the docs repo to be clear that calling .defined and .Bool on Junction does not create a new Junction object holding the result-values (in contrast to all other methods and subs/operators).

[vrurg]

Actually, it's incorrect behavior. It is absolutely unambiguously stated that junctions only collapse in a boolean context. defined is not one. So, all(Any, "foo").defined is all(False, True). I'd rather open an issue on this and get it done correctly.

[lizmat]

So you're saying we would need to change the behaviour of Raku since 2016?

I think at this point, it'd be better to change the documentation. As apparently this hasn't been an issue for the past 8 years.

[lizmat]

The current behaviour was changed/implemented without further discussion

At the time, @TimToady was still very much involved in development, so I wouldn't necessarily take the lack of discussion as a sign this was done singlehandedly by @zoffixznet, but rather as a sign that nobody thought it strange enough to warrant a discussion about it.

[vrurg]

If it gets documented then there must be a remark about the behavior to be changed in the future. It would be great if the change can be done for 6.e only, but our current model of versioning makes it too difficult.

so I wouldn't necessarily take the lack of discussion as a sign this was done singlehandedly by @zoffixznet

Unfortunately, this wouldn't be the first time when I stumble across some code where Zoffix was reacting without giving deeper insight into the matter. Once it was about fixing an erroneous test in Roast. Coincidentally, it was something about junctions too. :)

[lizmat]

If it gets documented then there must be a remark about the behavior to be changed in the future.

But why would it need to be changed? What's the use of a Junction filled with Bools as opposed to a single Bool to which it will collapse at some point anyway?

Could you give an example of when this would make a difference?

[vrurg]

No, I don't have such an example in my mind. But then why (^10).all > 3 wouldn't collapse immediately into a single Bool? What makes defined different from any other boolean-producing op? Yet, we have clear definition as to when junctions collapse and – no, defined doesn't fit the definition. Way of exceptions is the way that contributed to public negativity towards Perl.

As a side note, there are ways to "introspect" individual eigenstates. Say, the most primitive one with foo( (^10).all ). This is where the current behavior of defined may play its role.

[zoffixznet]

To me, it looks like a bug in the test. The description of the subtest in 6b84580ecc states the test is meant to test the fact that .defined does autothread. The tests themselves appear to just check the bool result (potentially is-deeply-junction should be used instead

roast/packages/Test-Helpers/lib/Test/Util.rakumod

Lines 26 to 44 in 8640e3a

	sub is-deeply-junction (
	Junction $got, Junction $expected, Str:D $desc
	) is export is test-assertion {
	sub junction-guts (Junction $j) {
	$j.gist ~~ /^ $<type>=(\w+)/;
	my $type := ~$<type>;
	my @guts;
	my $l = Lock.new;
	$j.THREAD: { $l.protect: {
	when Junction { @guts.push: junction-guts $_ }
	@guts.push: $_
	}
	}
	@guts .= sort;
	[$type, @guts]
	}
	is-deeply junction-guts($got), junction-guts($expected), $desc;
	}

). OP in Raku/old-issue-tracker#5801 states .defined failing to autothread is a bug and comment Raku/old-issue-tracker#5801 (comment) states that was fixed.... which appears it hasn't been.

What's the use of a Junction filled with Bools

Don't remember much about how/what it should be like, but to add to the above example from vrurg, there's also potential for different multies to be called:

$ R -e '
    multi foo(Mu) { say "Quantum Situation" };
    multi foo(Any) { say "simple situation" };
    foo 42 & 20;
    foo defined 100 & 10; 
 '
Quantum Situation
simple situation