I suspect we all know the obvious answer, but I think it’s rather hard to verify that it’s the right answer. For example, not all major compilers (e.g. msvc) even support Annex G. Does it mean there is something wrong with the standard?
Another answer might be, that Annex G still has small user base. For example, the GNU GSL supports (incorrectly) native complex numbers since 2021, while it’s API has all primitives for mixed-mode arithmetic.
Also, it seems most (all?) current compilers, supporting Annex G, implement mixed-mode arithmetic for real operands. Should we interpret this, that only that part of the approach, advocated by Kahan, is important? For me, it seems that removal message from the WG 14 just ignores all mathematical arguments for this feature (e.g. WG’s documents, quoted in my post).
BTW, in principle, I think we can avoid new type at cost of adding some special forms for the complex constructor (mostly invisible for users). Say, complex(real=x, pure=True) (a copy of real line) and complex(imag=y, pure=True) (for pure-imaginary numbers). Imaginary literals will be translated to the second form. Also, doing complex arithmetic, floats will be automatically coerced to the first form. The rest (i.e. arithmetic rules) is same as in the proposed version. But I suspect that this implementation will be more complicated internally.
Maybe positive? What’s bad in replacing incorrect or meaningless answers like (cmath.inf+1j)*2 currently?
For the mpmath it eventually allows to drop some boilerplate code and write instead:
@defun_wrapped
def acot(ctx, z):
return ctx.atan(ctx.one / z)
@defun_wrapped
def asec(ctx, z):
return ctx.acos(ctx.one / z)
@defun_wrapped
def acsc(ctx, z):
return ctx.asin(ctx.one / z)
(And silently fix all functions, that now miss required checks for special complex numbers :-))
For the gmpy2, mixed-mode rules could be implemented as for CPython. As it was noted before, the MPC library has all primitives to support this.