GNU bug report logs - #47368
28.0.50; map-elt returns nil without "deprecated" TESTFN

Previous Next

Package: emacs;

Reported by: dalanicolai <dalanicolai <at> gmail.com>

Date: Wed, 24 Mar 2021 22:54:02 UTC

Severity: normal

Tags: patch

Found in versions 28.0.50, 27.1

Fixed in version 28.1

Done: "Basil L. Contovounesios" <contovob <at> tcd.ie>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Adam Porter <adam <at> alphapapa.net>, Nicolas Petton <nicolas <at> petton.fr>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 47368 <at> debbugs.gnu.org
Subject: bug#47368: 28.0.50; map-elt returns nil without "deprecated" TESTFN
Date: Wed, 15 Sep 2021 10:26:20 +0100
Michael Heerdegen [2021-09-15 02:48 +0200] wrote:

> "Basil L. Contovounesios" <contovob <at> tcd.ie> writes:
>> What was the conclusion?  That map-elt should use equal for alists?
>
> That was the least controversial solution discussed, at least to my
> impression.
>
> But would that include to change the default of `alist-get', too?  I
> guess these should behave consistently.

That sounds a bit too radical to me within the scope of this bug report,
and for Emacs 28.  Since alist-get has the type in its name, and allows
for a testfn argument, I personally don't see any conflict between
map-elt and alist-get having different default behaviour on alists.

> [ Personally I would still be interested in an answer to the question:
> why don't we consider to keep the TESTFN arg at least for the list map
> type case? ]

I don't feel too strongly either way, and it's not my decision, but I
guess the point is that if you already know that your map is an alist,
then you can "customise" the behaviour of map-elt by using a different
accessor function, since map.el wants to provide a type-agnostic API.

Thanks,

-- 
Basil




This bug report was last modified 3 years and 329 days ago.

Previous Next


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