bug#68244: hash-table improvements

[Mattias Engdegård]

13 feb. 2024 kl. 13.43 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> A more worrying problem is code that uses `obarray-make` but assumes the
>> result to be vectors.  It may be unsafe to let obarray-make return an obarray
>> object for that reason.
> 
> I don't think it'd be "unsafe": it just introduces a bit
> of incompatibility.
> But `obarrayp` has been with us since Emacs-25 and it's trivial to
> change code using `vectorp`, so I wouldn't worry about it.

If we can do that, it's naturally preferable. Let's see how it goes.

>> With Stefan's suggestion, if I understood it right,
>> we'd have `obarray-make` return (vector 0).
> 
> I did not suggest such a thing.

Sorry, didn't mean to misrepresent. I should have said that it is one way of 
implementing `obarray-make` if compatibility with vector-assuming code really 
is a serious concern.

> I think it's worth introducing a bit of incompatibility, for the benefit
> of a cleaner API.  Such incompatibility should be very easy to fix while
> still maintaining compatibility with old Emacsen (at least back to
> Emacs-25, where the `obarray-make` and `obarrayp` were introduced).

I'm all for it but those obarray functions weren't mentioned in NEWS at the 
time nor in the manual (which even today recommends, even mandates, use of 
make-vector) so perhaps we need a bridge?