bug#31715: cl-incf and cl-decf error out when passed a nil-valued variable as 'offset'

[Noam Postavsky]

Clément Pit-Claudel <clement.pitclaudel@live.com> writes:

> On 2018-06-04 18:58, Noam Postavsky wrote:
>> X is an optional macro parameter, so the "optionalness" applies at
>> compile time.
>
> I think I see what you mean, but I'm not entirely convinced (in part
> because the docstring doesn't say so, and in part because it doesn't
> seem worth it to break referential transparency: if we accept nil, we
> should also accept a variable that evaluates to nil).

Hmm, not sure if referential transparency makes much sense for macros.

Both SBCL and CLisp throw an error for (let ((x 1) (y nil)) (incf x y)),
although I can't see anything in the Common Lisp spec to decide either
way.  E.g., cltl2 says:

    If delta is not supplied, then the number in place is changed by 1.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node125.html

>> I think that would approximately double the cost of cl-incf in the
>> simple case.  And since you would expect cl-incf to be used in loops a
>> lot, that seems like a bad idea.
>
> I think we could still optimize the case in which we get an explicit nil.

As I wrote earlier, I was wrong about the optimization thing anyway (I
initially looked at the macro expansion output instead of the byte
compiler output).

> In the rest of Emacs there are lots of other examples.  Many of them
> (for example semantic-find-tags-by-name or calendar-increment-month)
> seem to work when passed a nil-valued variable, but many others behave
> like cl-incf (for example gnus-summary-article-score).

I don't think those are great examples of macros to emulate.
semantic-find-tags-by-name and gnus-summary-article-score look like they
should be (inline?) functions instead of macros.
calendar-increment-month doesn't use make-symbol for proper temp
variable hygiene.