From @masak

<masak> how do I make a custom op iffy?
<TimToady> well, equiv should dup iffy-ness, I'd think, along with all
the other attributes of an operator
<TimToady> tighter and looser are of course more problematic
<masak> should there maybe be an 'is iffy' trait?
<jnthn> That'd make sense to me...
<TimToady> or it could be intuited from the return type, possibly
<TimToady> presumably something that returns Bool is naturally iffy
<masak> all those things sound like frills on top of the mundane,
reliable mechanism...
<TimToady> yeah
* masak submits 'is iffy' NYI ticket

Here's something that works already​:

$ perl6 -e 'sub infix​:<≃>($l, $r) { $l == $r }; say 4 ≃ 5'
False

The following doesn't. The above clog should be read as a discussion
around that​:

$ perl6 -e 'sub infix​:<≃>($l, $r) { $l == $r }; say 4 !≃ 5'
===SORRY!=== Error while compiling -e
Cannot negate ≃ because it is not iffy enough
[...]

My suggestion is to simply use 'is iffy' for this which today doesn't
work simply because it's Not Yet Implemented. As far as I can see,
this code oughta work when it is​:

$ perl6 -e 'sub infix​:<≃>($l, $r) is iffy { $l == $r }; say 4 !≃ 5'
===SORRY!=== Error while compiling -e
Can't use unknown trait 'is iffy' in a sub+{precedence} declaration.
[...]

TimToady has two other suggestions which also make sense to me, but
only in special cases.

S03 doesn't mention 'iffy' at all. S99 does​:

=head2 iffy

Used of an operator that either returns a C<Bool> result, I<or something like
it> (such as a match object). All the comparison operators are iffy, as are
conditional operators like C<&&>, C<?^>, and C<or>. C<%%> is iffy, but C<%>
isn't. The junctive operators are iffy.

The reason that we care about iffy operators is that you can only append the
C<!> metaoperator to an operator that's iffy.

The term originated in STD.pm6, and up until this ticket I'm aware of
no effort or discussion to make it user-facing. I'm not tied to any
one particular mechanism for exposing iffiness to userland, but I
firmly believe that it should be exposed; otherwise built-in operators
will have an advantage over user-defined ones, which feels un-Perlish.

From @AlexDaniel

Still NYI (2017.11, HEAD(5929887))

On 2014-08-30 01​:58​:28, masak wrote​:

<masak> how do I make a custom op iffy?
<TimToady> well, equiv should dup iffy-ness, I'd think, along with all
the other attributes of an operator
<TimToady> tighter and looser are of course more problematic
<masak> should there maybe be an 'is iffy' trait?
<jnthn> That'd make sense to me...
<TimToady> or it could be intuited from the return type, possibly
<TimToady> presumably something that returns Bool is naturally iffy
<masak> all those things sound like frills on top of the mundane,
reliable mechanism...
<TimToady> yeah
* masak submits 'is iffy' NYI ticket

Here's something that works already​:

$ perl6 -e 'sub infix​:<≃>($l, $r) { $l == $r }; say 4 ≃ 5'
False

The following doesn't. The above clog should be read as a discussion
around that​:

$ perl6 -e 'sub infix​:<≃>($l, $r) { $l == $r }; say 4 !≃ 5'
===SORRY!=== Error while compiling -e
Cannot negate ≃ because it is not iffy enough
[...]

My suggestion is to simply use 'is iffy' for this which today doesn't
work simply because it's Not Yet Implemented. As far as I can see,
this code oughta work when it is​:

$ perl6 -e 'sub infix​:<≃>($l, $r) is iffy { $l == $r }; say 4 !≃ 5'
===SORRY!=== Error while compiling -e
Can't use unknown trait 'is iffy' in a sub+{precedence} declaration.
[...]

TimToady has two other suggestions which also make sense to me, but
only in special cases.

S03 doesn't mention 'iffy' at all. S99 does​:

----

=head2 iffy

Used of an operator that either returns a C<Bool> result, I<or
something like
it> (such as a match object). All the comparison operators are iffy, as
it> are
conditional operators like C<&&>, C<?^>, and C<or>. C<%%> is iffy, but
C<%>
isn't. The junctive operators are iffy.

The reason that we care about iffy operators is that you can only
append the
C<!> metaoperator to an operator that's iffy.

----

The term originated in STD.pm6, and up until this ticket I'm aware of
no effort or discussion to make it user-facing. I'm not tied to any
one particular mechanism for exposing iffiness to userland, but I
firmly believe that it should be exposed; otherwise built-in operators
will have an advantage over user-defined ones, which feels un-Perlish.

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