# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #65638]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=65638 >
<masak> I have a few edge cases I'd like to discuss.
<masak> rakudo: sub infix:<,> { 42 }; say 5, 5
<p6eval> rakudo 1af7e2: OUTPUT«55»
<masak> I think this one should at least warn of overriding.
<masak> (secondly, it doesn't work.)
<moritz_> masak: a warning isn't that easy...
<moritz_> masak: because the setting will define a 'proto infix:<,>'
<moritz_> masak: so that any 'sub infix:<,>' is automatically a multi sub
<masak> moritz_: oh.
<moritz_> masak: and adding a new multi never warns
<masak> moritz_: well, then it shouldn't warn.
<masak> moritz_: but I bet it shouldn't not work either.
<masak> rakudo: sub infix:<#> { 42 }; say 5 # 5
<p6eval> rakudo 1af7e2: OUTPUT«5»
<moritz_> masak: it should do an ordinary multi dispatch
<masak> along the same lines...
<masak> moritz_: aye.
<masak> moritz_: and probably ambig-fail.
<moritz_> rakudo: sub infix:<,>(Int $x where 1, Int $y where 1) { 42 }; say 1, 1
<p6eval> rakudo 1af7e2: OUTPUT«11»
<masak> rakudo: sub infix:<+> { 42 }; say 5 + 5
<p6eval> rakudo 1af7e2: OUTPUT«42»
<moritz_> now *that* should be tighter, and give 42
* masak submits rakudobug
<moritz_> masak: a sub without a signature has slurpy @_
<masak> oh, right.
<moritz_> masak: so that it's not very specific, and will practically
never match in the multi dispatch
<masak> rakudo: sub infix:<+>() { 42 }; say 5 + 5 # so should this
<p6eval> rakudo 1af7e2: OUTPUT«42»
<moritz_> that should be 10, no?
<masak> I think so.
<masak> rakudo: sub infix:<+>($a, $b) { 42 }; say 5 + 5
<jnthn> I think the issues with overloading existing rather than
defining new, may be an interaction between the existing ones using
Parrot's MMD.
<p6eval> rakudo 1af7e2: OUTPUT«42»
<jnthn> And the new ones using Rakudo's.
<masak> aha.
<masak> jnthn: is there a plan to do something about that?
<jnthn> masak: Oh, actually, that bug is exactly coming up because of
this issue.
<jnthn> masak: The other issue is that since we're not really defining
a proto yet, your sub is just supplanting the existing operator.
<jnthn> masak: And yes, plan is to define all operators in Perl 6.
(With inline PIR, no doubt.)
<jnthn> When that happens, the special-cased auto-threading froms can
go away too. :-)
