go/types, types2: enable `real`, `imag` and `complex` with type parameter arguments

[griesemer]

For 1.18 we disabled (report an error) when applying one of these built-in functions to arguments of type parameter type because it involves the creation of a synthetic type parameter which may break go/types API invariants if those types leak.

Need to investigate what the correct approach is (e.g., should we track the type parameters in the types.Info.Implicits map?) and re-enable the code. The compiler may also need minor adjustments.

cc: @findleyr
cc: @ianlancetaylor

[gopherbot]

Change https://golang.org/cl/382116 mentions this issue: go/types, types2: disallow real, imag, complex on type parameters

[fgm]

Shouldn't that limitation be mentioned in the docs ? 4fea593 only contains code changes.

[griesemer]

@fgm, yes, doc changes are forthcoming.

[gopherbot]

Change https://golang.org/cl/381967 mentions this issue: doc/go1.18: document restrictions for real, imag, complex

[mdempsky]

Creating pseudo TypeParams to represent these derived types seems okay, but feels a bit inconsistent to me with how structural typing works otherwise in Go and the go/types API. If there's no declared name in the source file (i.e., no TypeName), then I think representing it as a TypeParam seems not ideal.

Could we instead create new Types to directly represent "type operations"? Like suppose we had types.FloatOf and types.ComplexOf, so that given value z of complex type C, FloatOf(C) would represent the type of real(z).

I expect we'll need a types.ElemOf operation too, if we allow things like dereferencing pointers of whose type is constrained to *P|*Q.

[findleyr]

inconsistent to me with how structural typing works otherwise in Go and the go/types API

Just to make sure I'm not missing something: currently where a structural type is used we expose the structural type itself in the API, right? Are you aware of any other conventions?

Edit: @mdempsky

[griesemer]

Instead of providing type operations, perhaps we can redefine the built-ins in a backward-compatible way, for instance:

func real[Argument ~complex64|~complex128, Result ~float32|~float64](z Argument) Result

and record the built-in signature as such. Then all type parameters are declared.

[mdempsky]

@findleyr Sorry, when I wrote "structural typing" I meant as opposed to nominal typing (i.e., https://en.wikipedia.org/wiki/Structural_type_system). I didn't mean the Go-specific use case.

@griesemer But I think we need a way to establish that Argument and Result are related types? E.g., for

func F[C1, C2 constraints.Complex](z1a, z1b C1, z2 C2) {
  _ = real(z1a) + real(z1b) // ok
  _ = real(z1a) + real(z2) // ERROR
}

we need to know that for any C1 the real(z1a) and real(z1b) calls will always have the same corresponding derived type and thus are addable, but that real(z1a) and real(z2) may not be.

[griesemer]

We could make the Result constraint a magic type constraint function that depends on the Argument. Maybe if real applied to a type, it produces a type result:

func real[Argument ~complex64|~complex128, Result real(Argument)](z Argument) Result

Such a type function would only be permitted in constraints.
But it opens the door to all kinds of similar constructs which we may not want to entertain.