diff --git a/wscl-issues/draft/vector-push-type-error b/wscl-issues/draft/vector-push-type-error new file mode 100644 index 00000000..91c0baf4 --- /dev/null +++ b/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.