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
cmd/compile: inconsistent results with gccgo #39003
Comments
Related to #38905. |
Related to #31546. See also other related issues linked to there. |
I'd be inclined to say blank fields shouldn't be visible to reflection. They're not exported, they can't be accessed normally, and they can't be a source of field/method promotion. However, that could change field numberings, which is arguably a backwards incompatible change, if there are programs that hard code field numberings and assume that blanks will be included (as they are today). |
Why would that change field numbering? I believe one could implement that by having reflect always return the zero value when queried about a blank field, which would leave field numbering intact. |
@josharian By not visible to reflection, I meant omitting them completely from the reflection metadata. I.e., change NumField to return the number of non-blank fields. (As precedence for something like this, in Go 1.7 we stopped allowing access of non-exported methods via reflection: #15673.) As for synthesizing zero values when accessing blank fields, how would we handle UnsafeAddr for blank fields? |
I see (at least) three paths. (1) Leave behavior as-is. We've then covered up one more little corner of mess and left one corner messy. I find (2) the most appealing of these options. |
Stumbled upon this again. I'm inclined to say that gccgo's behavior is correct, or at least more consistent with the Go spec. The Go spec says:
But there's nothing that says that blank fields otherwise behave differently than other fields. In particular, there's nothing that says they're not initialized in unkeyed struct literals, or not copied in assignments, or not accessible by packages reflect or unsafe. |
Should the assignment take effect? package main
import "fmt"
type T struct {
_ int
_ bool
}
func main() {
var t1 = T{123, true}
fmt.Println(t1) // gc result: {0 false}, gccgo result: {123 true}
t1 = T{}
fmt.Println(t1) // both: {0 false}
} |
There's nothing in the Go spec to suggest otherwise IMO. I think both cmd/compile and gccgo are both inconsistent with the spec in that regard. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
What did you expect to see?
consistent results from gc and gccgo.
What did you see instead?
inconsistent results from gc and gccgo.
The text was updated successfully, but these errors were encountered: