r.all(r.F, {}) => true, the all function, why not add type check or return false when param not a list

[xuexianzhishang]

r.all(r.F, {}) => true if you past a param that is not a list, return false may be better?

the implement of all,
`_dispatchable(['all'], _xall, function all(fn, list) {
var idx = 0;

while (idx < list.length) {
...
}
return true
`
if list param don't have length , true will return. is it better way to return false if list pram do not have length?

[Joe Lissner]

When using R.all, I'm thinking of it as something along the lines of "If anything in my array fails this check, return false". If my list happens to be empty, then nothing failed the check, so I would expect true to return.

For example, imagine you have some code that wants to check if all children of a person are over the age of 18, and if not, tell the user that there may be inappropriate content or something.

• If the user has 2 kids, one under 18 and one over 18, then the prompt should show.
• If the user has 2 kids, and both are over 18, the prompt should not show
• If the user has 0 kids, the prompt should NOT show -- this is the use case where the list is empty, and therefor an empty list is true

[Fernando Basso]

I agree, with @jlissner. In other words, “if nothing failed the check, then return true.”

But if we do all(F, 0) or all(F, false) , even those will return true. 0 and false don't even have a length property, and the loop won't even run. It is not the case that nothing in the collect failed the predicate. On the contrary, nothing was even checked (except for the implicit check of the length property`).

One option would be to throw an error where the data type is something that doesn't uphold some contract (in this case, to have a length property which would more ore less mean the data can be iterated over), but Ramda follows the “garbage in, garbage out” approach. Client code must be sure to pass the expected types/structures.

See #2504 (comment).