-
Notifications
You must be signed in to change notification settings - Fork 18k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reflect: methods are sorted #30688
Comments
In Go, you’re allowed to declare methods on a type from various |
Not sure if this was a question for me, I have not written the spec for the compiler. I'm just saying that the current behaviour is surprising (to me, at least) and un/underdocumented. I assume the various Also, you cannot spread an |
Why does it matter for methods? The method set is just that, a set. Sets are unordered. Fields occupy memory and the ordering may be important. |
The order of the method set does matter when using |
If I carefully order and group the methods in my interfaces, it certainly matters to me. You may not care, and that is fine. Note that I really didn't expect this issue to somehow change the way methods are ordered (at least not short term), but as it came as a surprise to me (even after reading the documentation), I assume others will also share my surprise. But there is an argument here, that you may remember for Go 2, and that is that interfaces do not have fields, so |
The fields in a struct have an obvious order, as the struct can only be written in one way. The methods of a type can appear in any order and the effect for everything other than the reflect package is exactly the same. So we should document what the reflect package does and move on. (There is a good reason that the reflect package sorts methods by name: it permits faster determination of whether a type implements an interface, in |
To expand slightly on Ian's point, these two struct types are different;
but these two interface types are identical:
Given that the reflect package returns identical type.Type instances for identical types, it would not be possible to preserve the originally declared method order without leading to a contradiction. For example: https://play.golang.org/p/YfQBaFmE4Ls If methods were not sorted, then the above program would be required to return two different values for the two calls to the methods function, but by the definition of interfaces, exactly the same type is passed in both cases, so that's not possible. |
Change https://golang.org/cl/169597 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://play.golang.org/p/c91WyY2NI2l
What did you expect to see?
Order preserved for both fields and methods.
What did you see instead?
Sorted order for methods, preserved for fields:
I was writing a generator to marshal some interfaces to JSON. I suspect Go's JSON package uses reflection behind the scenes, and that the order is preserved because of the "fields only" restriction. This breaks once you try to add methods to the mix.
The documentation in both of the cases above is similar:
The text was updated successfully, but these errors were encountered: