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

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

@fgm, yes, doc changes are forthcoming.

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

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.

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

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.

@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.

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.

We could make the Result constraint a magic type constraint function that depends on the Argument.

This sounds similar to the RealOf type operator I described above, but with the extra complexity of representing real as a generic function instead of a builtin function. I'm not opposed to that, but do the extra indirections buy us anything? Or is there a distinction I'm missing?

I also don't think that solution generalizes to allowing dereferencing *P|*Q-constrained pointers, because there's no function call that we can add the magic type parameter constraints to.

I think that any discussion of how to handle these cases should also consider how to handle cases like

func First[T ~string | ~[]byte](s T) int {
    for _, c := range s {
        return int(c)
    }
}

Here c is either byte or rune. The code is fine if we can handle that case.

@ianlancetaylor My first proposal would be to have types.RangeKeyOf and types.RangeValueOf type operators, which represent the corresponding types assigned to the RangeStmt.{Key,Value} expressions, respectively.

But I think there's also value in trying to consider creating a common Type instance to represent all of these operations, rather than creating one-off Types for each operation.

I like @mdempsky's idea of type operations/functions types.FloatOf and types.ComplexOf I was thinking of it more in terms of rules, since there are only a limited number of them, but functions on types makes sense. Basically, the type operation is what the stenciler/instantiater can use to generate the final concrete or shape type for these particular cases when substituting in the type args of a generic function/method.

Since the shape type implementation may vary between compilers, it may be that thinking of these as an enumerated set of rules is a little better, since the compiler will have to implement the rule. I.e. if it sees a type type.RealOf(T), and the value of the T arg during instantiation is a shape like complex128, then it knows that the result type should be a shape like float64 (even though it hasn't even generated a shape like float64 before).

I definitely don't see any particular use in representing these dependent types as type parameters - but at the very least, they need to have a rule/function associated with them. (Or each compiler will just have to implement these rules independently based on the builtins/constructs being used at that point in the program.)

Moving to 1.21. Not a high priority.

#45049 describes a possible solution to this problem by introducing a generic complex type that may be parameterized with float32 and float64.

This will not happen for 1.21. Pushing to next cycle.