From @colomon

colomon​: rakudo​: multi a () { 1 }; multi a (*@​x) { 2 }; say a();
[2​:33pm] p6eval​: rakudo 18598d​: OUTPUT«Ambiguous dispatch to multi
'a'. Ambiguous candidates had signatures​:␤​:()␤​:(Object *@​x)␤in Main
(/tmp/8uPi9JrI7p​:2)␤»

This occurs with the current (2009/8/3 2​:33 PM EST) p6eval and with
"Chicago" on OS X.

--
Solomon Foster​: colomon@​gmail.com
HarmonyWare, Inc​: http://www.harmonyware.com

From @jnthn

On Mon Aug 03 11​:50​:06 2009, colomon@​gmail.com wrote​:

colomon​: rakudo​: multi a () { 1 }; multi a (*@​x) { 2 }; say a();
[2​:33pm] p6eval​: rakudo 18598d​: OUTPUT«Ambiguous dispatch to multi
'a'. Ambiguous candidates had signatures​:␤​:()␤​:(Object *@​x)␤in Main
(/tmp/8uPi9JrI7p​:2)␤»

This occurs with the current (2009/8/3 2​:33 PM EST) p6eval and with
"Chicago" on OS X.

I think in general, a non-slurpy should be seen as a more specific
candidate than a slurpy. I've tried to get this in place in git 2731d20.
It certainly makes this work. Added a test case to the spectests too.

Thanks,

Jonathan

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

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