hello,

> So in the case only one of them is provided, the specification decided
> that error-type gets the priority

do you know where this is documented?
Currently Im using the https://index.scheme.org/filterset/r7rs_all/%28srfi%252064%29test-error (which might not be an official source) but I also checked the spec https://srfi.schemers.org/srfi-64/srfi-64.html and the ordering importance is unclear.

I dont know if there are any limitations on how this is implemented, but a few thoughts:
- Required parameters should always come before optional parameters. This ensures that mandatory arguments are provided first, improving function clarity and usability
- There is a difference importance on the ordering of optional parameters. The more critical or frequently used ones should be earlier in the parameter list

and something unrelated, do you know if there is an issue tracker for discussions like this outside of this mailing list?

-------- Original Message --------
On 07/02/2025 23:16, Tomas Volf <~@wolfsden.cz> wrote:

>  "Notevn (via srfi-64 list)" <xxxxxx@srfi.schemers.org> writes:
>
>  > hello,
>  > new to to guile and scheme, and Im experimenting with the srfi-64 module.
>  >
>  > i noticed an inconsistency in the test runner:
>  >
>  > for example, given these two tests:
>  > (test-assert "truth" #t)
>  > (test-error "div by zero" (lambda () (/ 1 0)))
>  >
>  > when logging the test runner, the second one does not have a test-name value with the name of the test and instead have a expected-error with the name of the test.
>  >
>  > (i also tested test-equal and test-ewv  and both return a test-name value)
>  >
>  > is there a reason for this inconsistency?
>
>  The general philosophy behind the arguments seems to be that the
>  test-name is optional.  Fox example:
>
>  --8<---------------cut here---------------start------------->8---
>  (test-assert [test-name] expression)
>  (test-equal [test-name] expected test-expr)
>  --8<---------------cut here---------------end--------------->8---
>
>  However for `test-error', we have *two* optional arguments:
>
>  --8<---------------cut here---------------start------------->8---
>  (test-error [[test-name] error-type] test-expr)
>  --8<---------------cut here---------------end--------------->8---
>
>  So in the case only one of them is provided, the specification decided
>  that error-type gets the priority.  Seems to be in line with the
>  "test-name is optional" thinking, so I am not sure I would cal it an
>  inconsistency.
>
>  > am i doing something wrong?
>
>  Well, yes, you are passing only two arguments, so the string is passed
>  as the `error-type'.  Try this to test for any error while naming the
>  test:
>
>  --8<---------------cut here---------------start------------->8---
>  (test-error "div by zero" #t (lambda () (/ 1 0)))
>  --8<---------------cut here---------------end--------------->8---
>
>  Have a nice day,
>  Tomas
>
>  --
>  There are only two hard things in Computer Science:
>  cache invalidation, naming things and off-by-one errors.
>