Status: Passed v4 (8-1), as amended, Dec-91; v5 reflects the amendment
Reference: Draft 10.156
188.8.131.52 Initialization Arguments (p.7-6)
(which corresponds to CLtL-II 184.108.40.206, p.802)
220.127.116.11 Declaring the Validity of Initialization Arguments
(p.7-7) (which corresponds to CLtL-II 18.104.22.168, p.803)
7.3.5 Keyword Arguments in Generic Functions and Methods
(p.7-20) (which corresponds to CLtL-II 22.214.171.124, p.792)
Edit History: Version 1, 10/2/91, Kim Barrett
Version 2, 10/8/91, Kim Barrett (Moon & JonL comments)
Version 3, 10/11/91, Kim Barrett (more Moon comments)
Version 4, 11/20/91, Kim Barrett
(clarify :allow-other-keys, make references to 10.156 draft)
Version 5, 11-Feb-92, Kent Pitman
("has no effect on" => "suppresses" per X3J13 meeting amendment)
A careful reading of 88-002R indicates that users must specify
&ALLOW-OTHER-KEYS in the lambda-lists of methods for initialization functions
if the method also specifies &KEY, else risk having the generic function
keyword argument checking signal an error due to the presence of "slot
filling" initargs. (An error might not occur due to the presence of other
methods which already specify &KEY + &ALLOW-OTHER-KEYS).
Several implementors (and presumably users too) have misread the specification
as saying that &ALLOW-OTHER-KEYS in an applicable initialization method means
that initarg validation is suppressed for those protocols in which the method
The result is that the need for and meaning of &ALLOW-OTHER-KEYS in
initialization methods differs significantly from one implementation to
1. Change the syntax of the following generic functions to specify both &KEY
ALLOCATE-INSTANCE class &key &allow-other-keys
INITIALIZE-INSTANCE object &key &allow-other-keys
MAKE-INSTANCE class &key &allow-other-keys
REINITIALIZE-INSTANCE object &key &allow-other-keys
SHARED-INITIALIZE object slot-names &key &allow-other-keys
UPDATE-INSTANCE-FOR-DIFFERENT-CLASS previous current
It is of course possible to retain "&rest initargs" in the syntax description
when needed in the corresponding function description.
2. Clarify that the presence of &ALLOW-OTHER-KEYS in the lambda-list of an
applicable method relevant to the specified initarg validity checking for an
initialization protocol suppresses the validity checking.
3. Clarify that a true value for the initialization argument :ALLOW-OTHER-KEYS
disables initialization argument validation. Make the following changes Draft
10.156 in order make this clarification.
a. Remove the last sentence of the second paragraph of section 126.96.36.199
(p.7-6), which says
"Error checking of initialization argument names is disabled if the keyword
argument pair whose keyword is :ALLOW-OTHER-KEYS and whose value is non-NIL
appears in the initialization argument list."
b. Replace the last sentence of section 188.8.131.52 (p.7-7), which says
"The meaning of:ALLOW-OTHER-KEYS is the same here as when it is passed to an
"Validity checking of initialization arguments is disabled if the value of
the initialization argument :ALLOW-OTHER-KEYS is true."
The syntax entries for seven functions need to be modified.
A small change to "Declaring the Validity of Initialization Arguments" is
needed in order to clarify the handling of &ALLOW-OTHER-KEYS in initialization
Since &ALLOW-OTHER-KEYS needs to be specified somewhere if &KEY is specified
by any of the applicable methods, it is better to have the generic function
specify it, rather than requiring programmers to remember to include it in
every initialization method that also specifies &KEY.
(defclass test ()
((slot :initarg :slot-filler))
(defmethod initialize-instance :after ((x test) &key) nil)
(make-instance 'test :slot-filler 5)
-> currently might signal an error
-> returns instance of test under proposed change.
Both Lucid 4.0 and IIM 3.4 specify only &REST in the lambda-lists of the
listed generic functions and the specified methods for those functions, with
the implication that user defined methods which specify &KEY must also specify
&ALLOW-OTHER-KEYS in order to inhibit keyword argument checking by the generic
function from signaling an error due to the presence of "slot filling"
initargs. However, because generic function keyword checking has not yet been
implemented in either Lucid 4.0 or IIM 3.4, users may not be aware of this
requirement. In fact, in IIM 3.4 there are system-supplied initialization
methods that fail to meet this requirement, so there are some implementors who
aren't aware of this problem either.
Franz Allegro 4.0 appears to have the same behavior as described above for
Lucid 4.0 and IIM 3.4. In particular, generic function keyword checking has
not yet been implemented.
Symbolics CLOS and Chestnut's Lisp-to-C translator both specify &KEY and
&ALLOW-OTHER-KEYS in the lambda-lists of the listed generic functions. In
addition, if an applicable method for one of the protocols specifies
&ALLOW-OTHER-KEYS then the specified initarg checking for the protocol is not
Macintosh Common Lisp 2.0b3c4 has "&KEY &ALLOW-OTHER-KEYS" in the lambda list
for MAKE-INSTANCE, but all the others just use "&REST". This asymmetry is an
oversight due to the fact that the method combination code special cases them,
and elides normal generic function keyword checking for all of them (hence it
has never appeared as a "bug"). MCL (like Symbolics and Chestnut) also
provides the additional behavior that if one of the applicable methods
specifies &ALLOW-OTHER-KEYS then the initarg checking for the protocol is not
Cost to Implementors:
Some possibly tricky code in the implementation may have to be reexamined. In
some implementations it looks like this may involve simply ripping out some
Cost to Users:
Probably none in most cases. Since none of the implementations surveyed ever
signal an error for the described problem case, it is unlikely that any user
code exists which depends on an error being signaled.
Users can eliminate unnecessary &ALLOW-OTHER-KEYS from initialization methods
at their leisure, since its presence or absence has no effect.
However, those users who have made use of the fairly common but non-portable
meaning of &ALLOW-OTHER-KEYS in applicable methods as a means of suppressing
initarg validation would have to find some other mechanism for this purpose.
One possibility would be to define appropriate :AROUND or primary methods on
MAKE-INSTANCE that add :ALLOW-OTHER-KEYS T to the initialization arguments.
Users and implementors will know what &ALLOW-OTHER-KEYS in an initialization
method's lambda-list means. Programmers writing initialization methods that
specify keywords won't have to remember to include &ALLOW-OTHER-KEYS
Requiring all initialization methods that specify &KEY to also specify
&ALLOW-OTHER-KEYS is clearly unaesthetic, so this change is an improvement.
Interestingly, for one reason or another, none of the implementations surveyed
perform generic function keyword checking (as opposed to initarg checking) for
the functions affected by this proposal.
The possibility of having &ALLOW-OTHER-KEYS in the lambda-list of an
applicable initialization method mean that initarg validation should be
inhibited was discussed, especially in light of the fact that several of the
implementations surveyed already provide this behavior. However, some people
questioned whether this was really such a good idea, being unmodular and
perhaps *too* convenient. Also, making such a change would add a real cost to
users who weren't expecting this extension, since they would have to examine
occurances of &ALLOW-OTHER-KEYS in initialization methods to decide whether
they were left over from the time when it was (at least theoretically) needed
to inhibit generic function keyword checking or actually there to do the new