From @ShimmerFairy

<lue> r​: sub infix​:["@​"] ($a, $b) { "$a@​$b" }; say "me"@​"server"
<camelia> rakudo f86a1a​: OUTPUT«===SORRY!===␤No such method 'ast' for
invocant of type 'NQPMu'␤»

The infix​:["..."] form of declaration should at least have a better
error message.

From @masak

lue (>)​:

The infix​:["..."] form of declaration should at least have a better
error message.

Not just that. S02, S03, S06, and S12 contain examples of this syntax. So
at the upper end this should actually be allowed, not just have a better
error message.

Of course, arbitrary values inside the [] only make sense if they're
known at compile-time (constants, for example). Care will need to be
taken; tests will need to be written.

On the caller side, even runtime values are fine; see S12​:444 for an
example.

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

From @usev6

On Mon Sep 23 12​:09​:04 2013, masak wrote​:

lue (>)​:

The infix​:["..."] form of declaration should at least have a better
error message.

Not just that. S02, S03, S06, and S12 contain examples of this syntax. So
at the upper end this should actually be allowed, not just have a better
error message.

Of course, arbitrary values inside the [] only make sense if they're
known at compile-time (constants, for example). Care will need to be
taken; tests will need to be written.

On the caller side, even runtime values are fine; see S12​:444 for an
example.

Just a status update​: This does not work (yet). On the plus side there is no longer an internal error message​:

$ perl6 -e 'sub infix​:["@​"] ($a, $b) { 42 }'
===SORRY!=== Error while compiling -e
Colon pair value '"@​"' too complex to use in name
at -e​:1
------> sub infix​:["@​"]⏏ ($a, $b) { 42 }

From @peschwa

On Sat Jan 03 08​:51​:32 2015, bartolin@​gmx.de wrote​:

On Mon Sep 23 12​:09​:04 2013, masak wrote​:

lue (>)​:

The infix​:["..."] form of declaration should at least have a better
error message.

Not just that. S02, S03, S06, and S12 contain examples of this
syntax. So
at the upper end this should actually be allowed, not just have a
better
error message.

Of course, arbitrary values inside the [] only make sense if they're
known at compile-time (constants, for example). Care will need to be
taken; tests will need to be written.

On the caller side, even runtime values are fine; see S12​:444 for an
example.

Just a status update​: This does not work (yet). On the plus side there
is no longer an internal error message​:

$ perl6 -e 'sub infix​:["@​"] ($a, $b) { 42 }'
===SORRY!=== Error while compiling -e
Colon pair value '"@​"' too complex to use in name
at -e​:1
------> sub infix​:["@​"]⏏ ($a, $b) { 42 }

I've implemented this in Rakudo commit d0885e56e8fe1c2cd280e419ab3edfb9afe3443c, tests have been added to roast in commit 21a9ea0f2dd21294a7539a0bf474d465e356535e for this and the related ticket #​117737

From @usev6

On Sun Oct 04 05​:49​:52 2015, peschwa@​gmail.com wrote​:

On Sat Jan 03 08​:51​:32 2015, bartolin@​gmx.de wrote​:

On Mon Sep 23 12​:09​:04 2013, masak wrote​:

lue (>)​:

The infix​:["..."] form of declaration should at least have a
better
error message.

Not just that. S02, S03, S06, and S12 contain examples of this
syntax. So
at the upper end this should actually be allowed, not just have a
better
error message.

Of course, arbitrary values inside the [] only make sense if
they're
known at compile-time (constants, for example). Care will need to
be
taken; tests will need to be written.

On the caller side, even runtime values are fine; see S12​:444 for
an
example.

Just a status update​: This does not work (yet). On the plus side
there
is no longer an internal error message​:

$ perl6 -e 'sub infix​:["@​"] ($a, $b) { 42 }'
===SORRY!=== Error while compiling -e
Colon pair value '"@​"' too complex to use in name
at -e​:1
------> sub infix​:["@​"]⏏ ($a, $b) { 42 }

I've implemented this in Rakudo commit
d0885e56e8fe1c2cd280e419ab3edfb9afe3443c, tests have been added to
roast in commit 21a9ea0f2dd21294a7539a0bf474d465e356535e for this and
the related ticket #​117737

Great! I'm closing this ticket as 'resolved'.

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