#

## Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE Writeup

    Issue:        DEFSTRUCT-COPIER-ARGUMENT-TYPE
    Forum:	      X3J13
    References:   DEFSTRUCT (X3J13/92-102, pp8-5..6)
    Category:     CLARIFICATION
    Edit history: 07-Jul-93, Version 1 by Pitman
    Status:		Proposal RESTRICT passed 11-1 on letter ballot 93-306.

    Problem Description:

     The description of the :COPIER defstruct option doesn't say that the
     consequences of applying the defined copier to an object not of the
     structure type are undefined.

    Proposal (DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT):

     Change the first sentence of the second paragraph of the description
     of the :COPIER to:

       The automatically defined copier function is a function of one
       \term{argument}, which must be of the structure type being defined.

     In addition, the last sentence can be changed to the following:

       If the DEFSTRUCT :TYPE option was not used, the following
       equivalence applies:

        (<copier> x) = (copy-structure (the \param{structure-name} x))

    Test Case:

     (DEFSTRUCT S1 A B C)
     (DEFSTRUCT S2 A B C)

     (COPY-S2 (MAKE-S1 :A 3)) => ??

     Before this proposal, it is possible to interpret the definition to say
     that #S(S1 :A 3) might be returned here.  This proposal makes it clear
     that the consequences are in fact undefined.

    Rationale:

     This gives implementational freedom in a situation where no reasonable
     programmer would say that the behavior should be well-defined.

    Current Practice:

     LispWorks 3.1.0 signals an error in the test case (even in low safety code).

     Symbolics Genera 8.3 returns #S(S1 :A 3) in the test case.

    Cost to Implementors:

     None.  This change is upward compatible.

    Cost to Users:

     HOPEFULLY none.   It would be really ugly to imagine anyone taking advantage
     of the room that there is now.

    Cost of Non-Adoption:

     The spec is less tight.

    Benefits:

     Aesthetics.

    Editorial Impact:

     Very small.

    Aesthetics:

     Mostly the spec (and any resulting code) will be slightly cleaner this way.

    Discussion:

     This change is in response to comment Margolin #8.

     Pitman doubts that anyone will actually abuse the loophole that
     this comment is about, but think's it's reasonable to tighten things
     up just in case.

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