SETF-OF-APPLYSETF (APPLY #'foo ...)) can be used only for places "foo" whose SETF expansion is implemented in such a way that the last subform of the accessing form appears as the last argument of the storing call. The discussion and example imply that the SETF method for AREF is required to implemented in this way. Are there any other SETF places defined in the standard that are required to be usable with APPLY?
This is Loosemore's issue #28.
SETF (APPLY #'<place> ...) ...) work for the standard <place>s AREF, BIT, and SBIT, but document that the consequences of using any of the other standard SETF <place>s with APPLY are undefined.
This proposal does not change the behavior of (SETF (APPLY ...)) with user-defined SETF methods; any SETF methods that are defined by the user in such a way that the last subform of the accessing form appears as the last argument of the storing call continue to work with SETF of APPLY.
SETF places, AREF, BIT, and SBIT appear to be the only functions that are defined with &REST arguments and where one might have a real need to use them with APPLY. Not requiring (SETF (APPLY #'AREF ...) ...) to work might be seen as an incompatible change to the language since CLtL implies that it is legitimate. BIT and SBIT are very similar to AREF. Requiring other SETF places to work with APPLY might be seen as putting unnecessary restrictions on implementors.SETF method for AREF and friends, or write some special-case handling for these places in the SETF method for APPLY.SETF of APPLY with other standard SETF places are almost certainly nonportable anyway.ONLY-AREF-AND-FRIENDS. It is probably closest to the status quo, but it seems like an overly complicated and messy way of dealing with a few special cases.
From a purely esthetic point of view, it would be much cleaner to require that the SETF method for AREF be implemented by a function (SETF AREF) and then either remove the SETF-of-APPLY feature completely or redefine it so that (SETF (APPLY #'<name> . <args>) <value>) is equivalent to (APPLY #'(SETF <name>) <value> . <args>) except for preserving the left-to-right order of evaluation of the original call. This kind of change might be seen as too much of a restriction on implementors and too major to be considered at this point, however. See issue SETF-FUNCTIONS-AGAIN.