Re: empty-directory predicate, native implementation

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: arthur.miller@live.com,  emacs-devel@gnu.org
>> Date: Wed, 14 Oct 2020 18:21:21 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think 0 doesn't make much sense, so we might as well not support
>> > that at all.
>> 
>> In general, I agree. Calling directory-files with COUNT being 0,
>> literally, doesn't make sense. But COUNT could be the result of some
>> arithmetics, and instead urging the caller to test it, we could simply
>> return nil. Which is correct, reading nil as the empty list.
>> 
>> And it doesn't cost us anything.
>
> I'm okay with interpreting "don't support" as "return nil".

Attached is patch which return nil early.

I was thinking a bit when it would be useful to return length; the only
thing I come up is to maybe allocate some structure, a vector or
something based on how many files there are without really carying about
files. In case there are many such objects, there would be lots of list
the lisp system does not care about, and GC will have to work a lot
unnecessary, but i think it is probably very rare case if not very
artifical, so nil is just fine for the most use-cases.

dired.c.patch
Description: dired.c.patch