Antero,

>> - Existing implementation practice. Kawa has an `as` form that coerces
>>   the passed values to the necessary type when possible. Kawa
>>   implementation of SRFI-253 uses `as` in `values-checked`, as the
>>   closest implementation-specific approximation of `values-checked`.
>
> Is it correct to assume that only `values-checked` does coercion? Can
> any of the other forms in the SRFI coerce values?

Oh, right. `let-checked` uses `values-checked` in sample implementation,
so it is affected too. Not sure what to do with it.

> OK. Can the wording be updated to something like:
>
> "Implementations may choose to coerce the values when the types are
> compatible (e.g. integer -> inexact)."
>
> That way the implementer can decide whether to be permissive or
> strict.

Yes, that sounds good to me.

> Also the SRFI text says "(e.g. int -> float)", but float is not
> specified in R7RS so I assume it means inexact, which is usually
> represented by a float.

Fixed that too:
https://github.com/scheme-requests-for-implementation/srfi-253/pull/10/commits/41d0a877da3f8e49d49a0b53ae2a44e531d7f871

> My concern is that coercion could cause subtle changes in behavior or
> breakage, in rare cases. A contrived example:
>
> ```
> (define (add-one x)
>   (values-checked (inexact?) (+ x 1)))
>
> (display (inexact? (add-one 3))) ; different output in debug mode
> ```

With your wording suggestion, the behavior is implementation-dependent
in this particular case—implementation might coerce or not, regardless
of debug mode.

I have to think some more about it. You're making good cases. Thanks!

--
Artyom Bologov
https://aartaka.me