proposal: reflect: treat reflect.Type as a pointer where possible for generics & maps

[twmb]

reflect.Type cannot be used in any comparable generic code. As well, using reflect.Type as a key in maps compiles to ifaceeq when it could be compiled to pointer / number comparisons.

Because reflect.Type has two internal methods, there cannot be any implementation outside of the reflect package. Inside reflect, Type is always *rtype which corresponds to a runtime type.

Can we solve #51179 by specially compiling reflect.Type to its *rtype representation, which makes it comparable? As well, can this force the discussion on #32303 by committing to "No, custom type implementations are not supported"?

Lastly, storing pointers in maps rather than reflect.Type can help speed up essentially any serializer that caches some computation of reflect.Type => {reflect.StructField}. Notably, there is a map[reflect.Type]something in encoding/binary, encoding/gob, encoding/json, and encoding/xml. I noticed this myself when writing a serializer for avro (I know others already exist). For the small toy struct that is commonly used in avro tests, serialization speeds up from 350ns to 300ns. In benchmarks, looking up reflect.Type is ~12ns, vs. ~2ns for unsafe.Pointer -- it's a small increase, but it does add up, especially when using arrays.

[uluyol]

It is possible to wrap a reflect.Type and override methods.

[twmb]

Interesting wrinkle in my hopes, I think wrappers may make any intrinsic "this is *rtype a bit muddled. Fundamentally a wrapped reflect.Type is still an *rtype, but any added fields mean we aren't comparing two *rtypes anymore.

The other angle I was thinking to propose: is it worth considering adding something like reflect.UnsafeTypePointer to receive the underlying type pointer?

[ianlancetaylor]

My personal preference here is to adopt #51338 and change reflect.Type to embed comparable. Then no special handling is required.

[twmb]

#51338 is great and largely covers it, albeit @Merovius brought up the same wrinkle. I think #51338 is a better general approach, whereas this issue would be an optimization regardless of what's chosen. If the wrinkle cannot be solved, is it worth it to consider an alternative proposal of extracting the *rtype as a unsafe.Pointer somehow?

[rsc]

It sounds like we should decline this in favor of #51338.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group