GNU bug report logs -
#29165
26.0.90; can't use some code byte-compiled under emacs 24
Previous Next
Reported by: Ken Raeburn <raeburn <at> permabit.com>
Date: Mon, 6 Nov 2017 06:58:02 UTC
Severity: normal
Tags: fixed, patch
Found in versions 26.1, 26.0.90
Fixed in version 27.1
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> (And if we’re going to make that sort of thing an error, we should
>>> probably check whether empty &key or &aux variable lists are similarly
>>> rejected. I haven’t looked.)
>
> I recently installed a patch to fix/improve the behavior of &aux with no
> keyword variable (I bumped into it while working on some Elisp package,
> tho I can't remember which right now).
>
> I think it's usually worth the small extra effort to support &optional
> not followed by any var (as well as &aux not followed by any var) since
> it sometimes comes in handy. But not if it costs extra at run-time.
I don't think there is any performance penalty (when running
byte-compiled code anyway). Although I see that &optional at the end of
the arglist has been a compile error for a long time (I tested back to
24.3). E.g., (defun foo (&optional)) fails to compile. (defun foo
(&optional &rest)) happened to work, though I wouldn't exactly call that
"support".
>> Updated patch which handles &aux as well. I also tested a bootstrap
>> (doing this I found the previous patch messed up some positive cases).
>
> To the extent that &aux is only handled by macro-expansion, accepting an
> empty &aux never costs anything at run-time, so I think rejecting it is
> a disservice to our users.
I don't see the use case for empty &aux, but I don't mind reverting that
change.
This bug report was last modified 7 years and 137 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.