Repository navigation
Semantics for maximumOn & friends #362
Description
Activity
I think we should clearly document existing behaviour of all four functions, but do not modify
maximumOnto follow deprecated behaviour ofmaximumBy. Doing otherwise will just increase an amount of potential breakage in 0.13.I don't understand what do you mean by this.
maximumOn&maximumByshould behave identically otherwise we'll have two function that do same thing but slightly differently.Real question is whether we should keep change to
maximumByfrom return first to return last, or should we revert to definition from 0.12 (return first).Real question is whether we should keep change to maximumBy from return first to return last, or should we revert to definition from 0.12 (return first).
I'm in favor of reverting #180.
basedoes not specify tie behaviour ofminimumBy/maximumBy, and theoretically can change it in any major release (which happens pretty often). We should not be chase compatibility with it entirely at our own expense. #180 introduced a dangerous silent breaking change, and I do not think that the motivation was strong enough.Reacted by Alexey KuleshevichReacted by Alexey Kuleshevich- added 2 commits that reference this issue
on Mar 5, 2021
This is followup to #356. I stumbled on it while writing doctests. in #180 maximumBy definition was changed.
Data.List & vector0.13
minimumByreturns first tiemaximumByreturns last tievector-0.12
minimumByreturns first tiemaximumByreturns first tiemaximumOn should I think match behavior of maximumBy. Question is whether we should match functions for lists which aren't very consistent or should revert to 0.12
P.S. Data.Foldable.maximumBy function definition doesn't make any promises on ties