Add isNotEmpty

[Harris-Miller]

This MR adds a new function isNotEmpty. It is implemented the same way isNotNil is, in how that it just returns !isNil(), this just returns !isEmpty().

isNotEmpty is not a particularly useful addition to ramda when it comes to pure vanilla javascript, however, it is extremely useful in typescript

Specifically for arrays, the typings for isNotEmpty can type narrow a T[] to a NonEmptyArray<T>. This type behavior can be combined with the usage of functions like head, which can be overloaded to know the difference, allowing for a strict return type of T instead of T | undefined. And that, is invaluable

Here is a full example in the Typescript Playground

I'll eventually have an MR in types-ramda to compliment this one with full typings as demo'd in the playground link

[kedashoe]

Looks like we might have kept dist and got rid of everything else?

edit: 👍 btw

[Harris-Miller]

@kedashoe Yeah I've been wondering why dist is committed. When I npm run build on my local it updates dist and I have to reset those files before committing (or forget to and make another commit to change it back, like I had to here)

[kedashoe]

@kedashoe Yeah I've been wondering why dist is committed. When I npm run build on my local it updates dist and I have to reset those files before committing (or forget to and make another commit to change it back, like I had to here)

Ya we should have the default npm run build not include updating dist. I'll put up a PR for that before the next release.

[Harris-Miller]

@kedashoe At work today, a dev of mine harmlessly switched an instance of isEmpty in our code from being imported from lodash to ramda

Caught by a unit test, we found that lodash.isEmpty handles null/undefined differently from ramda.isEmpty

• _.isEmpty(null) => true
• R.isEmpty(null) => false

It makes since to me why ramda would want to return false there. Because null/undefined are not "empty", they can't be "empty" because they don't contain anything to be "empty" of

That made me realize that this MR has a flaw. In that isNotEmpty() is just !isEmtpy(), for the case of null/undefined it is incorrect. isNotEmpty(null) should also return false

The best analogy I have for this is that isEmpty(null) === false AND isNotEmpty(null) === false in the same way that 5 < 5 === false AND 5 > 5 === false

Before I trhow up a second MR, was hoping to get some feedback on my assertion

[kedashoe]

👍 , I agree with your reasoning

[Harris-Miller]

errrr.... thinking about this more, I don't think we should do what I'm suggesting above

Because that would also mean that !isEmpty() !== isNotEmpty() for all cases. As well as complement(isEmpty)() !== isNotEmpty(). Objectively, introducing that discrepancy in behavior is worse than solving for what I suggested above. And is anything. Best to keep it as is. If anything, it would be Breaking. I wouldn't want devs to start replacing !isEmpty() in their code with isNotEmpty() and have them find out them behave differently

[kedashoe]

Fair enough, really it is a type error for null/undefined, which would mean !isEmpty() == isNotEmpty() again, but not so easy considering plain js vs typescript