WSCL issue: VECTOR-PUSH-TYPE-ERROR

wscl-issues/draft/vector-push-type-error

@@ -0,0 +1,73 @@
+Issue:          VECTOR-PUSH-TYPE-ERROR
+Forum:          Cleanup
+Category:       CLARIFICATION
+Status:         draft
+Edit History:   16-May-24, Version 1 by Jin-Cheng Guu
+References:     VECTOR-PUSH
+
+Problem Description:
+
+  In the draft ANSI Common Lisp specification, the description of the
+  functions VECTOR-PUSH and VECTOR-PUSH-EXTEND indicates no exceptional
+  situations for when the NEW-ELEMENT is not of a type indicated by the
+  ELEMENT-TYPE of the VECTOR.
+
+Proposal (VECTOR-PUSH-TYPE-ERROR:SIGNAL-ERROR-IN-SAFE-CODE):
+
+  This proposal changes the description of the VECTOR-PUSH function, so that
+  the section "Exceptional Situations" instead reads:
+
+  "The functions VECTOR-PUSH and VECTOR-PUSH-EXTEND should signal an error of
+  type TYPE-ERROR if given a NEW-ELEMENT not of a type indicated by the
+  ELEMENT-TYPE of the VECTOR.
+
+Test Cases:
+
+  (defun one ()
+    (declare (optimize (safety 3)))
+    (vector-push 0 (make-array 5 :fill-pointer 2
+                                 :element-type 'character
+                                 :initial-element #\a)))
+
+  (one) ; => [signals TYPE-ERROR with expected type CHARACTER]
+
+Rationale:
+
+  We think it was a simple omission from the draft ANSI specification to
+  indicate no exceptional situations.
+
+Current Practice:
+
+  SBCL 2.4.1
+    (one) => [signals type-error]
+
+  ECL 23.9.9
+    (one) => [signals simple-type-error]
+
+Cost to Implementors:
+
+  Very small. We believe that most implementations are already signaling an
+  error in safe code. Some implementations may signal a simple error, and
+  those implementation would need to signal a type-error instead.
+
+Cost to Users:
+
+  None.
+
+Cost of non-adoption:
+
+  Application programmers may need to add numerous explicit checks to be
+  certain that their code is conforming.
+
+Benefits:
+
+  Application programmers may rely on an error being signaled in safe code,
+  and thus avoid having to add explicit checks in portable code.
+
+Aesthetics:
+
+  No influence.
+
+Discussion:
+
+  N/A.