FWIW there are two layers to this ticket: failure on operators, and
faiures within where clauses.
The error is due to a failure during evaluation the where clause
and does not say '$x' for the same reason this does not:
$ perl6 -e 'my Int $x; my $f = $x > 0;'
Invocant requires an instance of type Int, but a type object was passed. Did
you forget a .new?
... The "invocant" is because the '>' operator is finding its candidate
through class methods. That cannot be improved at the runtime bind
site as variable names have been optimized away. Rejecting :Us earlier
in the bridgework might allow the error to occur earlier where more
information is still available, and that would give an eject marker
at the right character in the code:
$ perl6 -e 'sub b (Str $a) { }; sub f(Int $x where { b(3) } ) { say "yup" }; my
Int $a; f($a);'
===SORRY!=== Error while compiling -e
Calling b(int) will never work with declared signature (Str $a)
at -e:1
------> ub b (Str $a) { }; sub f(Int $x where { ⏏b(3) } ) { say "yup" }; my Int
$a; f($a)
...but it has to be done with care for optimizability and could be messy
what with all the multi candidates involved.
As a sidenote, it is not very idiomatic to repeat the parameter name in the
parameter's own where clause, and it would normally be written:
sub f(Int $x where * > 0)
...and FWIW using Int:D would yield:
$ perl6 -e 'sub f(Int:D $x where * > 0) { say "yup" }; my Int $a; f($a);'
Parameter '$x' requires an instance of type Int, but a type object was passed.
Did you forget a .new?
But whether failures that occur during a runtime constraint check should
emit a worry to identify the offending where clause is a good question.
Perhaps where clauses could have an extra implicit CATCH... worry... rethrow,
since they tend to be called so close to the binder.
