Opened 12 years ago

Last modified 20 months ago

#242 assigned defect

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

Reported by: rschlatte Owned by: rschlatte
Priority: minor Milestone: 1.9.2
Component: compiler Version: 1.2.0-dev
Keywords: Cc:
Parent Tickets:

Description

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".

Change History (21)

comment:1 Changed 12 years ago by rschlatte

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

comment:2 Changed 12 years ago by 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… ;)

comment:3 Changed 12 years ago by 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.

comment:4 Changed 12 years ago by ehuelsmann

Owner: changed from ehuelsmann to rschlatte
Status: newassigned

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

comment:5 Changed 12 years ago by Mark Evenson

Milestone: 1.2.0
Version: 1.2.0-dev

comment:6 Changed 11 years ago by Evenson Not Org

Milestone: 1.2.01.3.0

comment:7 Changed 11 years ago by Mark Evenson

Milestone: 1.3.02.0

Ticket retargeted after milestone closed

comment:8 Changed 11 years ago by Mark Evenson

Milestone: 2.02.0.0

Milestone renamed

comment:9 Changed 11 years ago by Mark Evenson

Milestone: 2.0.01.4.0

comment:10 Changed 8 years ago by Mark Evenson

Milestone: 1.4.01.5.0

Ticket retargeted after milestone closed

comment:11 Changed 7 years ago by Mark Evenson

Milestone: 1.5.01.6.0

Ticket retargeted after milestone closed

comment:12 Changed 5 years ago by Mark Evenson

Milestone: 1.6.01.6.1

Ticket retargeted after milestone closed

comment:13 Changed 5 years ago by Mark Evenson

Milestone: 1.6.11.6.2

Ticket retargeted after milestone closed

comment:14 Changed 4 years ago by Mark Evenson

Milestone: 1.6.21.7.0

comment:15 Changed 4 years ago by Mark Evenson

Milestone: 1.7.01.7.1

Ticket retargeted after milestone closed

comment:16 Changed 4 years ago by Mark Evenson

Milestone: 1.7.11.7.2

Ticket retargeted after milestone closed

comment:17 Changed 4 years ago by Mark Evenson

Milestone: 1.7.21.8.0

Milestone renamed

comment:18 Changed 4 years ago by Mark Evenson

Milestone: 1.8.01.8.1

Ticket retargeted after milestone closed

comment:19 Changed 3 years ago by Mark Evenson

Milestone: 1.8.11.9.0

comment:20 Changed 21 months ago by Mark Evenson

Milestone: 1.9.01.9.1

comment:21 Changed 20 months ago by Mark Evenson

Milestone: 1.9.11.9.2
Note: See TracTickets for help on using tickets.