SETF-OPTIONAL-ARGUMENTSSETF is silent on the question of how to treat place forms for functions which permit optional arguments. For example, it says that you can SETF a GETHASH expression, but it doesn't say what that means when the optional argument is provided.
A consequence of any outcome of this clarification should be to advise users about how they should write SETF methods of their own, since enforcing any chosen protocol requires programmer cooperation.
(DEFVAR *HT* (MAKE-HASH-TABLE)) ;Line 1 (GETHASH 'A *HT*) => NIL, NIL, NIL ;Line 2 (SETF (GETHASH 'A *HT* 0) 0) => 0 ;Line 3 (GETHASH 'A *HT* 0) => 0, T, A ;Line 4 (GETHASH 'A *HT*) => ?? ;Line 5
SETF is called on a place which permits optionals, it is an error to specify the optionals.
This makes line 3 of the test case have "undefined consequences".
SETF is called on a place which permits optionals, the optional arguments are ignored.
This makes the result on line 5 of the test case be 0, T, A.
SETF is called on a place which permits optionals, only the effect of that particular pattern of optionals needs be updated.
This makes the result on line 5 of the test case be NIL, NIL, NIL.
SETF is called on a place which permits optionals, the implementation is free to either ignore the optional arguments or to exactly invert the expression.
This makes the result on line 5 of the test case be either NIL, NIL, NIL or 0, T, A.
DISALLOW-OPTIONALS avoids what some might see as a questionable situation.
IGNORE-OPTIONALS makes the behavior of later accesses without the optional more reliable in some cases. It also eliminates the need to guard against an optional creeping in when a macro is constructing a SETF form from other code.
INVERT-EXACTLY permits the implementation to optimize storage usage in some cases. It also gives what some feel is a cleaner `conceptual' description of the overall intent of SETF.
EXPLICITLY-VAGUE is a fall-back in case of committee deadlock.
IGNORE-OPTIONALS.If a particular implementation has documented its behavior on this point and is forced to change, some documentation impact might occur.
IGNORE-OPTIONALS because he guesses that's current practice in most implementations, and hence offers greatest linguistic stability. If it turns out that implementations vary widely in current practice, though, his preference might lean more toward INVERT-EXACTLY due to aesthetic appeal.