#

## Issue INITIALIZATION-FUNCTION-KEYWORD-CHECKING Writeup

    Status: Passed v4 (8-1), as amended, Dec-91; v5 reflects the amendment
    Issue:          INITIALIZATION-FUNCTION-KEYWORD-CHECKING
    Reference:      Draft 10.156
    		  7.2.1.1 Initialization Arguments (p.7-6)
    		    (which corresponds to CLtL-II 28.1.9.1, p.802)
    		  7.2.1.2 Declaring the Validity of Initialization Arguments
    		    (p.7-7) (which corresponds to CLtL-II 28.1.9.2, p.803)
    		  7.3.5 Keyword Arguments in Generic Functions and Methods
    		    (p.7-20) (which corresponds to CLtL-II 28.1.6.5, p.792)
    Category:       CHANGE
    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)

    Problem Description:

     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
     takes part.

     The result is that the need for and meaning of &ALLOW-OTHER-KEYS in
     initialization methods differs significantly from one implementation to
     another.

    Proposal:

     1. Change the syntax of the following generic functions to specify both &KEY
     and &ALLOW-OTHER-KEYS:

       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
    				       &key &allow-other-keys
       UPDATE-INSTANCE-FOR-REDEFINED-CLASS object
    				       added-slots discarded-slots
    				       property-list
    				       &key &allow-other-keys

     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 7.2.1.1
      (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 7.2.1.2 (p.7-7), which says

       "The meaning of:ALLOW-OTHER-KEYS is the same here as when it is passed to an
        ordinary function."

      with

       "Validity checking of initialization arguments is disabled if the value of
        the initialization argument :ALLOW-OTHER-KEYS is true."

    Editorial impact:

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

    Rationale:

     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.

    Examples:

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

    Current Practice:

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

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

    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
     special cases.

    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.

    Performance Impact:

     None.

    Benefits:

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

    Aesthetics:

     Requiring all initialization methods that specify &KEY to also specify
     &ALLOW-OTHER-KEYS is clearly unaesthetic, so this change is an improvement.

    Discussion:

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.