On 9/21/26 09:56, D Guthrie wrote:
 > Signalling is not optional. Invalid UTF-8 bytes must always error.
Does my 'should' then 'may' language create ambiguity?

I find "should raise an assertion violation" to make it sound like
raising the exception is optional, and that such an exception has
specified irritants. I would suggest:

 > If the information is available, then the exception raised when
invalid sequences of UTF-8 octets are detected should have the offending
octet and its position within the bytevector as irritants.

___________________

 > No, an assertion violation should only be raised when I use the
language explicitly. I'm very unsure of the least-restrictive language
which would admit using conditions if available. I have found it
difficult to tell what the typical conventions are with respect to
conditions in existing SRFI proposals.

In that case, the "UTF-8 interpretation" should be modified to mention
errors and not assertion violations. For example, "update-iri-user"
section uses "error" and links to that section, which mentions assertion
violations.

The wording "an error is raised" is very similar to "an error is
signaled," where the latter means that an error of any type is signaled
(in R7RS jargon). I think that being explicit about the difference is
useful:

 > In this SRFI, "an error is raised" means that an error is signaled
that is of type &error.

I agree that the conventions are not clear.

-- Peter McGoron