RE: empty-directory predicate, native implementation

[Drew Adams]

Sorry I'm coming to this late.  It's a long thread,
and I've only checked your patch, not the messages.

I don't understand why we would do this.  Is the
real aim to be able to have an empty-directory
predicate, i.e., to be able to see if there are
no files in a directory?

If so, then why not do just that, witout
bothering (changing the signature of)
`directory-files'?

Is there really some use case for getting only
the first N files in a directory?  I can
understand wanting to test whether a dir is
empty.  I can't see why someone would want the
first N files (however "first" might be defined).

The doc string itself seems to suggest that the
(only?) use case is to test for emptiness:

 You can use this function to short circuit evaluation
 in case you are just interested to find if a directory
 is empty or not (request one file and tell it to
 ignore dot-files).

That need is clear enough.  But what else is
COUNT useful for?  How about having the doc
string also tell us what we can use a COUNT
value > 1 for?  That's the case that really
needs pointing out, not the empty-dir-p case.

And what is the order that defines which file
is first, second, etc.?  Without knowing that,
what use is getting the "first" N?

If this has already been raised, discussed,
and dismissed, fine - apologies for the noise.
If not, what's the raison d'etre for adding
optional parameter COUNT?

Why not just add a predicate `directory-empty-p'?