DEFSTRUCT-SLOTS-CONSTRAINTS-NAMESYMBOL-NAME of the slot designator; the meaning of slot accessors and the constructor function is unspecified.SYMBOL-NAME of the slot names should not be STRING=. This holds when they were both named directly by the same call to defstruct or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name "should signal an error." (While not yet formally defined, the intent is that the error signalling may occur when compiling a file that contains duplicate names or when evaluating a DEFSTRUCT form with duplicate names in an interpreter.)
This proposal only affects the operation of the DEFSTRUCT macro, and not the STRUCTURE-CLASS or structures defined with DEFCLASS>
:include struc1)) slot) if preceded by (defstruct struc1 slot).
(defstruct struct package-1:slot package-2:slot) is also an error. Slot accessors are interned in the current *PACKAGE* at the time of the evalution of the DEFSTRUCT.
DEFSTRUCT, it should be considered an error.KCL, if two slots have the same name, no warning message is given but mysterious behavior ensues. (Their default values are both whatever is given for the second one, neither can be given a different value via a call to the constructor function, only the second one's value can be changed by setf...)Aethetics:
Something that is not well-defined and leads to erratic behavior should be explicitly considered an error.
This issue was first circulated to X3J13 June 1988.
This proposal does not address the issue of whether NIL is a legitimate slot name. There seems to be no current reason why it might be prohibitied.
The compiler committee is proposing to address generally the issue of how macro-expansion errors during compile-file might be caught and turned into compiler warnings.