From @masak

<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. :-)

From @kyleha

This is an automatically generated mail to inform you that tests are now available in t/spec/S06-operator-overloading/sub.t

commit 18aadd8fead78ab26ce3d1fd22f30443fbfd310f
Author​: kyle <kyle@​c213334d-75ef-0310-aa23-eaa082d1ae64>
Date​: Wed Oct 14 21​:25​:41 2009 +0000

  [t/spec] Test for RT 65638
 
  git-svn-id​: http://svn.pugscode.org/pugs@&#8203;28792 c213334d-75ef-0310-aa23-eaa082d1ae64

diff --git a/t/spec/S06-operator-overloading/sub.t b/t/spec/S06-operator-overloading/sub.t
index 326c3e7..136e9d9 100644
--- a/t/spec/S06-operator-overloading/sub.t
+++ b/t/spec/S06-operator-overloading/sub.t
@@ -2,7 +2,7 @@ use v6;
 
 use Test;
 
-plan 56;
+plan *;
 
 =begin pod
 
@@ -372,4 +372,18 @@ Testing operator overloading subroutines
 
 }
 
+# RT #65638
+{
+    is eval('sub infix:<,>($a, $b) { 42 }; 5, 5'), 42, 'infix:<,>($a, $b)';
+    is eval('sub infix:<,>(Int $x where 1, Int $y where 1) { 42 }; 1, 1'), 42,
+       'very specific infix:<,>';
+    #?rakudo todo 'RT 65638'
+    is eval('sub infix:<#>($a, $b) { 42 }; 5 # 5'), 42, 'infix:<#>($a, $b)';
+    #?rakudo 2 skip 'Redefinition of infix:<+> causes Test.pm to miscount'
+    is eval('sub infix:<+>() { 42 }; 5 + 5'), 10, 'infix:<+>()';
+    is eval('sub infix:<+>($a, $b) { 42 }; 5 + 5'), 42, 'infix:<+>($a, $b)';
+}
+
+done_testing;
+
 # vim: ft=perl6

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

From @moritz

Test plasses now, closing ticket.

@moritz - Status changed from 'open' to 'resolved'