Please discuss the merit of the JEP in the linked discussion. PR discussion should be limited to proofing the content of the PR and the PR proposal initial comment
I don't understand why a JEP is needed. This is a lot of overhead just to submit a small editorial change.
Abstract
This PR changes the wording of the spec to state the specific error type in all error scenarios.
I have found several occurrences of the word "error" in the spec. In most cases, the spec indicates the exact type of error, e.g., invalid-type, unknown-function, invalid-arity. However, there were a few occurrences when no explicit error type is mentioned.
In two cases, I think the right error type is invalid-type. In the third case (Slices section), I'm not sure what the error type should be. Maybe invalid-value, but it's not specified anywhere in the spec (I see only three error types defined).
- If the given step is 0, an error MUST be raised.
+ If the given step is 0, an `invalid-value` error MUST be raised.
Editorial changes to indicate the exact error type
Please discuss the merit of the JEP in the linked discussion. PR discussion should be limited to proofing the content of the PR and the PR proposal initial comment
I don't understand why a JEP is needed. This is a lot of overhead just to submit a small editorial change.
Abstract
This PR changes the wording of the spec to state the specific error type in all error scenarios.
I have found several occurrences of the word "error" in the spec. In most cases, the spec indicates the exact type of error, e.g.,
invalid-type,unknown-function,invalid-arity. However, there were a few occurrences when no explicit error type is mentioned.In two cases, I think the right error type is
invalid-type. In the third case (Slices section), I'm not sure what the error type should be. Maybeinvalid-value, but it's not specified anywhere in the spec (I see only three error types defined).Implementation Survey
Not relevant