Bug #40905 for List-MoreUtils: Returning undef when none is passed an empty array is counterintuitive

This is resolved in 0.23 which I just uploaded to the CPAN.

On Fri Oct 11 01:09:04 2013, REHSACK wrote: Show quoted text
I think the problem here is looking at these in isolation. In order to get a coherent API, let's (whether we actually add the section or not) invent a proposed "what functions do when passed an empty list" section and list each one, its behaviour, and why that behaviour is consistent conceptually. Note that I'm not suggesting we simply rationalise the current behaviour, but instead propose a consistent set of behaviour - so if somebody wants to propose such a section, they should annotate where the behaviour changes from the current. REHSACK, since you asked for the discussion, I hereby nominate you to produce the first proposal to provide a starting point. Well volunteered :D

In many ways this is analogous to the question of sum/product on empty lists. You can draw an analogy between sum and any, by noting the properties of addition vs boolean inclusive-or and the identities 0 and false (and ignoring for this argument the predicate function given to 'any', we'll consider that A,B,C are the boolean results of the predicate function mapped over the original input list): sum A,B,C = A + B + C = 0 + A + B + C sum A = A = 0 + A sum () = 0 any A,B,C = A | B | C = false | A | B | C any A = A = false | A any () = false To have any return false on an empty list is consistent with its description - it failed to find any value in the input list that satisfied its predicate, so it must return false. Turning now to product and all, we can note again the properties of multiplication vs boolean and, and the identities 1 and true: product A,B,C = A * B * C = 1 * A * B * C product A = A = 1 * A product () = 1 all A,B,C = A & B & C = true & A & B & C all A = A = true & A all () = true Having all return true on an empty list is also consistent with its description - it could find no counter-example to the claim "all these values pass the predicate", so it must return true. In all four cases, sum, product, any, all, they are simply the (associative) list reduction of their input lists over their respective binary operator, starting from the identity value of that operator function op id sum + 0 product * 1 any || false all && true This is furthermore hinted at by the example definitions of these functions in terms of the base 'reduce' case: reduce { $a || $predicate->(local $_ = $b) } 0, @list # any reduce { $a && $predicate->(local $_ = $b) } 1, @list # all By way of a final motivation, you can also note the generalisation of DeMorgan's law applied to the any/all: A & B == not( (not A) | (not B) ) all { PREDICATE } LIST == not any { not PREDICATE } LIST For this to remain true even when the LIST is empty, it is required that any and all on empty lists return complementary values - all true, any false. Finally, I don't believe any of these functions should ever return undef - they are boolean predicate tests so should always return a defined boolean value. -- Paul Evans

The question was at no point, what has List::MoreUtils in API - the point was, that it has changed without permission and asking back by hijacker. Sorry for inconvinience - but after 10 years you can ask for custom and practice. You're chance here is to argue - and I completely follow LeoNerd's explanation, even if I think there is some truth in my point of view, too. But hijacked custom and practice is - sorry - not a valid reason to keep it.

Resolved by switching to Sub::Exporter and allow users to choose between alias implementation and tassilo's. WIth 0.401 alias implementation will be announced being depreciated and some time later a warning will be issued when using ':all' and even some more time later ':all' will disappear.