proposal: reflect/type.go: func (t *structType) Field(i int) (f StructField) Why not delete the memory allocation？

[Fgaoxing]

Proposal Details

I noticed the problem with #2230, but this allocation is so performance-impairing that it consumes hundreds of nanoseconds more, it's almost pointless, and the "index" is the same as the incoming "i", which can be deleted entirely. If you are worried about compatibility, you can also provide a new method without deleting the old one (this may cause new history issues, but compatibility will be better). The problem with this method is that packages seeking high performance have to use the "unsafe" and "namelink" methods instead of directly using "toType" and "toRtype", which may also lead to an additional risk of memory leaks, which are dangerous and destabilizing (this may be similar to the "reflect.SliceHeader" problem).

[gabyhelp]

Related Issues and Documentation

• proposal: reflect: improve the speed of getting field name from struct and elements from slice #47099 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

Note: the issue reference in the top comment should be to #2320.

We can't change the definition of StructField; that would break existing programs and the Go compatibility guarantee. We aren't going to introduce a new variant of StructField that duplicates the existing definition.

Closing as infeasible.

[gopherbot]

Change https://go.dev/cl/597855 mentions this issue: reflect: avoid allocation in structType.Field common cases