From @gfldex

# rakudobug_infix​:<=>.p6
class A is Hash {

}

multi sub infix​:<=>(A $a, Str $value){
  #we throw the new value away, doesn't really matter for this bug
  return $a;
}

sub b() {
  return A.new();
}

say b = 'foo';

$ perl6 'rakudobug_infix​:<=>.p6'

No applicable candidates found to dispatch to for 'infix​:<=>'. Available
candidates are​:
:(A $a, Str $value)

  in main program body at line 15​:rakudobug_infix​:<=>.p6

--
Nobody knows the age of the human race, but everybody agrees that it is
old enough to know better.
  -- Anonymous

From @Kodiologist

I added some tests to S03-operators/assign.t (roast fd5e4b1e2e).

@Kodiologist - Status changed from 'new' to 'open'

From @diakopter

the behavior now matches STD. closable with testneeded imho.

12​:50 <diakopter> r​: https://gist.github.com/2823010
12​:50 <p6eval> rakudo e2d876​: OUTPUT«===SORRY!===␤Preceding context
expects a term, but
  found infix = instead␤at /tmp/mpC4bIAkzk​:14␤»
13​:03 <diakopter> std​: https://gist.github.com/2823010
13​:03 <p6eval> std f179a1b​: OUTPUT«Use of uninitialized value $x in
pattern match (m//) at
  STD.pm line 66577.␤Use of uninitialized value $x in
concatenation (.) or
  string at STD.pm line 66616.␤===SORRY!===␤Preceding
context expects a term,
  but found infix = instead at /tmp/_D4jAg9d6d…

class A is Hash {

}

multi sub infix​:<=>(A $a, Str $value){
#we throw the new value away, doesn't really matter for this bug
return $a;
}

sub b() {
return A.new();
}

say b = 'foo';

From @Mouq

Behavior only matches STD because we were parsing incorrectly before. "=" has lower precedence than function calls, so the fact that it dies is like the fact that "foo && bar" dies (where the correct code would be "foo() && bar" or "foo and bar")

The issue remains that multi candidates aren't called. Besides the test in S03-operators/assign.t, here's a command line golf​:

perl6 -e'class A is Hash {}; multi infix​:<=>(A $,Str$) { 42 }; say A = "foo"'
Odd number of elements found where hash initializer expected
  in method STORE at src/gen/m-CORE.setting​:10842
  in block <unit> at -e​:1

The correct behavior would be to print 42.

On Tue May 29 11​:05​:28 2012, diakopter.gmail.com wrote​:

the behavior now matches STD. closable with testneeded imho.

12​:50 <diakopter> r​: https://gist.github.com/2823010
12​:50 <p6eval> rakudo e2d876​: OUTPUT«===SORRY!===␤Preceding context
expects a term, but
found infix = instead␤at /tmp/mpC4bIAkzk​:14␤»
13​:03 <diakopter> std​: https://gist.github.com/2823010
13​:03 <p6eval> std f179a1b​: OUTPUT«Use of uninitialized value $x in
pattern match (m//) at
STD.pm line 66577.␤Use of uninitialized value $x in
concatenation (.) or
string at STD.pm line 66616.␤===SORRY!===␤Preceding
context expects a term,
but found infix = instead at /tmp/_D4jAg9d6d…

class A is Hash {

}

multi sub infix​:<=>(A $a, Str $value){
#we throw the new value away, doesn't really matter for this bug
return $a;
}

sub b() {
return A.new();
}

say b = 'foo';

From @jdv

The premise of this ticket seems invalid as per below so closing.

12​:34 < jdv79> m​: class A is Hash {}; multi infix​:<=>(A $,Str$) { 42 }; say A = "foo" # what should happen here?
12​:34 <+camelia> rakudo-moar 71fab7​: OUTPUT«Cannot bind attributes in a type object␤ in block <unit> at /tmp/w4QbviuYJo​:1␤␤»
12​:36 < jnthn> Well, for one infix​:<=> is not invoked through multi-dispatch, but rather a primitive.
12​:36 < jnthn> So it boils down to the same as the code without the multi
12​:37 < jnthn> I suspect it then tries to .STORE, which maybe is not marked with :D which would give an error sooner
12​:37 < jnthn> m​: Hash.STORE(42)
12​:37 <+camelia> rakudo-moar 71fab7​: OUTPUT«Cannot bind attributes in a type object␤ in block <unit> at /tmp/VIPAAUn_3s​:1␤␤»
12​:38 < jnthn> m​: Hash.^lookup('STORE').signature.say
12​:38 <+camelia> rakudo-moar 71fab7​: OUTPUT«Use of Nil in string context at /tmp/kChuFr10BI line 1␤(EnumMap​: Any \to_store, *%_)␤»
12​:38 < jnthn> Yeah, it wants a :D on there I guess
12​:45 < jdv79> jnthn​: does that mean https://rt-archive.perl.org/perl6/Ticket/Display.html?id=76734 is invalid?
12​:47 < jnthn> jdv79​: I think so...provided TimToady agrees = is primitive rather than multi-dispatch (at least for the time being), but I think we settled on that for a while

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

@usev6 - Status changed from 'resolved' to 'rejected'

From @usev6

For the records​: I removed the (skipped) test for this ticket from S03-operators/assign.t with commit Raku/roast@511b3d1e7b