You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In e.g. the documentation for the reflect package, concrete types like Value have their methods listed and documented individually, while interface types like Type do not, but force the reader to grovel through the actual source code of interface to find the methods declared on the type. This is a great inconvenience to the reader, particularly because as a consequence the interface type's methods are not listed in the table of contents.
It seems particularly egregious in cases like reflect.Type where the concrete types that fulfil the interface are all unexported, and the user is unlikely to be creating more. The fact that Type is an interface is of no real interest to the reader, and should not affect the format in which the documentation is presented.
The text was updated successfully, but these errors were encountered:
cpcallen
changed the title
godoc should format interface types more like other types, displaying method separately
godoc should format interface types more like other types, displaying methods individually
May 11, 2017
Drat, didn't see that, despite searching for it. Maybe I was looking only for bugs tagged 'documentation', but I guess it really is a bug against godoc functionality rather than documentation... Sorry!
Looks like we can close this (we prefer to avoid duplicate issues and this indeed looks like a dup of #5860). Please comment if I'm missing something and this should stay open. Thanks.
In e.g. the documentation for the
reflect
package, concrete types likeValue
have their methods listed and documented individually, while interface types likeType
do not, but force the reader to grovel through the actual source code of interface to find the methods declared on the type. This is a great inconvenience to the reader, particularly because as a consequence the interface type's methods are not listed in the table of contents.It seems particularly egregious in cases like
reflect.Type
where the concrete types that fulfil the interface are all unexported, and the user is unlikely to be creating more. The fact thatType
is an interface is of no real interest to the reader, and should not affect the format in which the documentation is presented.The text was updated successfully, but these errors were encountered: