# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #122653]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=122653 >
<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.
