Yes, our complex numbers are pretty underspecified.

Complex arithmetic has lots of corner cases. There are multiple versions of infinity (inf+0i, 0+inf*i, etc.) and nans. As far as I know we don't normalize any of these corner cases.

Also the rounding story for complex numbers is unclear. You have to compute floating-point expressions like a*b+c*d, but how many roundings are allowed while doing that?

It will help us if you write down in more detail what you think we should specify.

In general the complex number supports follows Annex G of the C11 programming language standard, which describes how complex numbers should work in C.

/cc @griesemer for spec-related issues.

It will help us if you write down in more detail what you think we should specify.

For example, based on the compiler source code, it appears that this is how addition is implemented, assuming a and b are complex numbers:

return complex(real(a) + real(b), imag(a) + imag(b))

Multiplication appears to be done this way (ignoring widening/narrowing to do the multiplication in float64 instead of float32 for complex64):

r := real(a) * real(b) - imag(a) * imag(b)
i := real(a) * imag(b) + imag(a) * real(b)
return complex(r, i)

The spec could list this as pseudo-code, for example. That would make an implementation trivial. Of course, the spec should then also specify whether the widening done here is required or not - because I would want to avoid it in my implementation if it is not absolutely necessary.

When I take a look at the C11 spec regarding complex numbers, the given code is quite big. It takes special care of NaN and Infinity, which the Go compiler appears to completely ignore. So perhaps this is even a bug in the Go compiler, I don't know what the intended behavior is. It certainly shows that the Go language could use some more words regarding how complex numbers ought to work (and if the spec doesn't care about NaN/Inf, that's fine to me, but it should be specified IMHO).