Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> FWIW, I'd consider it an error if an entry in
>>> `package--builtin-versions` has a nil "version".
>>> There are no such things as "unversioned packages" in this respect.
>>> So, I think the code is OK but the docstring should not mention that
>>> we return nil for packages without a version.
>>
>> I think in principle you are correct given that the current public
>> functions don't provide a way to obtain such a symbol.  But it's
>> possible that someone can construct a symbol, either by hand or through
>> a new interface that queries all builtin packages, which is in
>> `package--builtins' but not in `package--builtin-versions', and the
>> function will return nil.  Do you think it's worth keeping such
>> possibility into consideration?
>
> Returning nil for packages (aka symbols) which aren't in
> `package--builtin-versions` is fine and I have no objection to
> documenting it.
>
> My objection is to
>
>     if @var{package} does not have a version
>
> but not to
>
>     if @var{package} ... is not a buil-tin package
>

I see.  Though technically people can get a package symbol from
`package--builtins', and hence built-in, but not in
`package--builtin-versions', and hence does not have a version
associated.  Maybe I can be more explicit to say "if @var{package} is
built-in but does not have a version ..."?  (Revised as such.)

> [ BTW, note the typo above.  ]

Thanks for spotting.  Also fixed.

>
>
>         Stefan
>

-- 
Regards,
Xiyue Deng