One of the reasons I've never felt the need for something like this is because the whole empty/non-empty distinction is not incredibly useful for generic code.
Most of the time, if you have a function which takes a generic collection, you're interested in processing more than a single element from it (otherwise you could use something like
c.first.map). If your function really does require a certain number of elements, it will already need to handle the case when the collection contains fewer elements than required. The empty vs. non-empty distinction is just a special case of that; having the caller check first if the collection is empty just adds noise and complexity.
Furthermore, the benefits (non-optional
last properties, etc) disappear the moment you do something like take a slice of the collection.
And then you need to consider the caller - having initializers with separate head and tail parameters is not very convenient. I'd say it's substantially more of a burden than having to unwrap
first for a collection you somehow know isn't empty.
You might say that generic code isn't a good candidate for
NonEmpty - but then, none of the other examples in the README are very compelling either, IMO. Take the GraphQL example - if an empty set of fields is literally the only error that could possibly happen when sending a request to a server, it might be worthwhile; but since that's obviously not the case, it ends up being a lot of fuss for very little benefit.
If anybody has some compelling examples of general classes of problems, where forcing the caller to deal with emptiness specifically apart from all other errors can have real benefits, I'd love to hear them.