unsafe instead of reflect? Or both?

unsafe instead of reflect? Or both?

Both. I just try to use unsafe, reflect and generics together to write a library, it is faster than my manual code to solve the same problem in my benchmark. amazing!!!
I know it just a benchmark game. But it is still amazing.

func SliceToMapFieldAsKey[Key_t comparable,Item_t any](s []Item_t,fieldName string) map[Key_t]Item_t{
	var key Key_t
	rkeyt:=reflect.TypeOf(key)
	m:=make(map[Key_t]Item_t,len(s))
	t1:=reflect.TypeOf(s)
	t1e:=t1.Elem()
	if t1e.Kind()!=reflect.Struct{
		panic(`only support slice of struct now.`)
	}
	f,ok:=t1e.FieldByName(fieldName)
	if ok==false{
		panic(`SliceToMap1 fieldName not found`)
	}
	if f.Type.ConvertibleTo(rkeyt)==false{
		panic(`SliceToMap1 fieldName type not match`)
	}
	offset:=mustGetOffsetFormStruct(t1e,fieldName)
	for i:=range s{
		key=*(*Key_t)(unsafe.Pointer(uintptr(unsafe.Pointer(&s[i]))+offset))
		m[key] = s[i]
	}
	return m
}
func mustGetOffsetFormStruct(rs reflect.Type,fieldName string) uintptr{
	f,ok:=rs.FieldByName(fieldName)
	if ok==false{
		panic(`fieldName not in struct`)
	}
	if len(f.Index)==1{
		return f.Offset
	}
	offset:=uintptr(0)
	for _,index:=range f.Index{
		rf:=rs.Field(index)
		offset+=rf.Offset
		rs = rf.Type
	}
	return offset
}

Do you have any suggestions for how to make the comment clearer?

It seems to me that the confusion is not so much about Offset as about the fact that FieldByName can return a field in an embedded struct.

Do you have any suggestions for how to make the comment clearer?

offset within defined struct, in bytes. If the field is embed in struct, it is the offset within the embedded struct. 

It may be better to add another func like reflect.GetOffsetFormStructByName(rs reflect.Type,fieldName string) (uintptr,bool) then add common with To get the offset of a embedded field within struct use GetOffsetFormStructByName.

It seems to me that the confusion is not so much about Offset as about the fact that FieldByName can return a field in an embedded struct.

I do not think so. I first use the StructField.Index, it tell me the index of embedded level. So I do not think StructField is return a field in an embedded struct

Wouldn't it be better to have a similar behavior with the StructField.Index method and return an array of offsets ?

Thus:

• the last element of an array is always an offset within a struct
• rest (prior to the last) elements are the offsets of the embedded structs

In this way, if an array contains one element, it's just an offset within the struct, if more - the struct is embedded. And you can leverage or just ignore that info and go with the last element, which is always an offset within the struct.

Wouldn't it be better to have a similar behavior with the StructField.Index method and return an array of offsets ?

I do not think this design is better, it will confuse/surprise me again.
I think add a field or method give me the answer of the offset within the caller struct is best.
In my use case (try to use unsafe to make reflect code run faster like github.com/viant/xunsafe ), an offset within the caller struct is useful and the offsets of the embedded structs is useless.

I don't see any reason to add new fields or functions or methods. All the information anybody might want is available and correct. As far as I can tell, this is a documentation issue that should be addressed by writing better documentation.

Change https://go.dev/cl/514035 mentions this issue: reflect: update StructField.Offset document

Thanks a lot .
I think we should also mention this information on StructField.Offset not only on Type.FieldByName.
Do we need to add this information on Type.Field , Type.FieldByIndex, Type.FieldByNameFunc?

I don't think we need a common on StructField.Offset. I think the existing comment there is exactly right. The only confusing case is when you look up a field and don't realize that it is a promoted field, and that is specific to the lookup.

We don't need any comment on Type.Field or Type.FieldByIndex. I think those cases are clear. But a common on Type.FieldByNameFunc would be appropriate, as that can also return a promoted field.