[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24
From: |
Noam Postavsky |
Subject: |
bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24 |
Date: |
Thu, 14 Dec 2017 20:16:20 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) |
Stefan Monnier <monnier@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.