If (when) this code stops working because of changes in perl, there will be a bug in the library. And this bug will be fixed (in a single place).
That is one of the most convoluted pieces of non-reasoning I've seen in a while.
Firstly, assuming that grep will (or even might) suddenly change in a breaking and completely illogical way is like allowing for the possibility that the Sun might rise in the West tomorrow. A theoretical possibility, but distinctly unlikely.
And even if grep did change; basing the correctness of your program on taking the statement that "The order of elements in the returned list is the same as in LIST.", as a guarantee, rather than just a statement of current reality, is naive in the extreme. What would you do if the author(s) decided "if its good enough for Perl, its good enough for us"? Sue.
I won't have to go through all my code and find all appearances of this code and fix it. I'd write my own function ...
The logic of putting common code in a subroutine -- the DRY principle -- is sound; but just as easily addressed by wrapping your posted code in a subroutine as it is by using a module.
Using List::MoreUtils::uniq() is a perfectly valid choice for any of several reasons, but on the basis of some inferred guarantee, isn't one of them.
In reply to Re^7: Order in which grep/map receive elements
by BrowserUk
in thread Order in which grep/map receive elements
by abufct
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |