addressing the issue of correlating built in structured types in generic code: float/complex

[Dan Kortschak]

Now that a proposal for an approach to generics has been approved[1],
it seems like a good time to again[2] raise the issue of how to be able
to write code that has correlated types where types are structured but
built-in, and so fields are not available to examine. The only case of
this in the language is the relationship between float and their
corresponding complex types. So for example in the case of wanting to
write a simple generic Eigen Decomposition functions we would have

type Real interface {
type float32, float64
}

func Eigen[T Real](m, n int, data []T) (left, values, right []?, ok bool) { ...

but, there is currently no way to specify that []? is a slice of
complex(T, T).

Having a syntax for this is obvious; being able to write []complex(T,
T) in this place is entirely consistent with doing the same thing with
structs where the types of struct fields are visible to the language
user. Indeed, in the current generics proposal, the Gonum quaternion,
dual, hyperdual and dual quaternion number types are easier to
integrate into a generics system than the built in complex number types
because they are based on structs.

Similarly, general utility functions that would be useful in DSP to
interconvert between complex and real would be

func AsComplex[T Real](v T) ? /* a complex(T, T) */ { ...

type Complex interface {
type complex64, complex128
}

func Abs[T Complex](v T) ? /* a float of the correct size */ { ...

Where in the latter being able to write real(T) to specify the type of
the return value.

Dan

[1]https://blog.golang.org/generics-proposal
[2]https://groups.google.com/g/golang-nuts/c/dZIdMJTO5ws/m/nQbBk7NrBgAJ

[Ian Lance Taylor]

For the record Dan followed up on this at https://golang.org/issue/45049.

Ian