Hi Stefan,

Xiyue Deng <manphiz@gmail.com> writes:

> 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.
>

Friendly ping.  I wonder whether the updated version is in a more
acceptable state?

> [...]

-- 
Regards,
Xiyue Deng