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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f0234521fc7b4127244ae87dd9086ff7310f3dff.camel%40kortschak.io.