Unused &key arguments in defmethod forms should not cause style-warnings

[rschlatte]

CLHS 7.6.5 says: "The lambda list congruence rules require that each method accept all of the keyword arguments mentioned after &key in the generic function definition, by accepting them explicitly, by specifying&allow-other-keys, or by specifying &rest but not &key."

Currently, when compiling a file containing the form

(defmethod foo ((x fixnum) &key y z) x)

we get style warnings about unused variables y and z. I think that these style warnings can be safely elided, since a typo in the arglist will lead to another style warning "Undefined variable A assumed special".

[rschlatte]

Pascal Costanza, the original reporter, commented on armedbear-devel (August 26 2012, "Re: warnings for method keywords (was Re: Closer-mop support for ABCL)"):

This is not the part I'm referring to. It's rather this one: "The set of keyword arguments accepted by the generic function for a particular call is the union of the keyword arguments accepted by all applicable methods and the keyword arguments mentioned after &keyin the generic function definition, if any."

To illustrate: Assume the following definitions.

(defgeneric foo (x y z &key a b c))

(defmethod foo ((x my-class) y z &key a b c d)
 (+ y z a b c))

If you invoke foo on an instance of my-class, the keyword parameter :d is accepted, although it is not used inside the body. This can be important, depending on circumstances (for example, when implementing specifications that require certain keywords to be accepted, as is the case for the CLOS MOP).

However, you seem to agree to drop the style warning, so that's ok… ;)

[ehuelsmann]

The best solution would be to take all keyword arguments from the generic function and, intersect them with the keys from the method function and add an IGNORABLE declaration for them: that'll generate style warnings for any keys specific for the method, but not for the ones inherited from the GF.

[ehuelsmann]

I'm assuming Rudi picks up this one. Please feel free to re-assign if that's not the case.

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Milestone renamed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Ticket retargeted after milestone closed

[Mark Evenson]

Milestone renamed

[Mark Evenson]

Ticket retargeted after milestone closed