Why not?
Or possibly a string variable or constant that is the name of the comparator function, though I'm not personally fond of that option.
You know, that's what it currently does. And it wouldn't make any difference in your case whether the comparator function were passed to sort as a coderef.
The problem is not that it's passing the function by name, it's how the parser decides whether an identifier at the given position is to be taken as a comparator function. I would have preferred if that required an ampersand and no parens; this would be analogous to a \&@ prototype (but of course the block is optional so sort still can't use a prototype) and would be unambiguous.
However, removing this special case from the parser at this point would break a lot of code so you're out of luck — it's ampersand and parens or a plus, no other option.
Makeshifts last the longest.
In reply to Re^3: implicit sort disables a chained subroutine?
by Aristotle
in thread implicit sort disables a chained subroutine?
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |