GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>, 68244 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#68244: hash-table improvements
Date: Wed, 14 Feb 2024 13:37:49 +0100

13 feb. 2024 kl. 13.43 skrev Stefan Monnier <monnier <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.