We allow "an implementation violation" for inexact non-real to exact, since implementations may not support ratios, but require implementations to support both exact and inexact complex. This may be too strong a requirement.

resolution␣invalid

statusnewclosed

On re-reading the text, I think it can be inferred that the disclaimer

If an exact argument has no reasonably close inexact equivalent, then a violation of an implementation restriction may be reported.also applies to complex numbers, despite the preceding statement

For exact complex numbers, the result is a complex number whose real and imaginary parts are the result of applying exact-> inexact to the real and imaginary parts of the argument, respectively.so there doesn't seem to be anything to change here, except potentially as an editorial clarification if someone comes up with better wording.

I agree; we should allow an implementation to support not having exact complex numbers.