From @AlexDaniel

Code​:
say { 0 => 1, 1 => 0 }.max(​:by(*.value))

Result​:
1 => 0

Code​:
say { 0 => 1, 1 => 0 }.max(*.value)

Result​:
0 => 1

I think :by(…) is something people commonly try (somebody did this on camelia, and I remember doing this myself), so it would be great if it could warn the user.

From @zoffixznet

On Thu, 05 Jan 2017 07​:59​:29 -0800, alex.jakimenko@​gmail.com wrote​:

Code​:
say { 0 => 1, 1 => 0 }.max(​:by(*.value))

Result​:
1 => 0

Code​:
say { 0 => 1, 1 => 0 }.max(*.value)

Result​:
0 => 1

I think :by(…) is something people commonly try (somebody did this on
camelia, and I remember doing this myself), so it would be great if it
could warn the user.

So why do people try it, anyway? Why that specific named param?

I rather not litter the code with heuristics to catch arbitrary named params.

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

From @zoffixznet

On Wed, 26 Apr 2017 06​:31​:06 -0700, cpan@​zoffix.com wrote​:

On Thu, 05 Jan 2017 07​:59​:29 -0800, alex.jakimenko@​gmail.com wrote​:

Code​:
say { 0 => 1, 1 => 0 }.max(​:by(*.value))

Result​:
1 => 0

Code​:
say { 0 => 1, 1 => 0 }.max(*.value)

Result​:
0 => 1

I think :by(…) is something people commonly try (somebody did this on
camelia, and I remember doing this myself), so it would be great if
it
could warn the user.

So why do people try it, anyway? Why that specific named param?

I rather not litter the code with heuristics to catch arbitrary named
params.

I see our docs call the arg `&by` for this routine. I clarified[^1][^2] in
the docs that this is a positional and not a named arg and IMO we should
not add any changes to Rakudo's source for this ticket.

[^1] Raku/doc@2f8f417
[^2] Raku/doc@67ab9c1

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