For what it's worth, I am (unsurprisingly) a big fan of the filename-based constraints. It's a lightweight convention that has served us incredibly well. I really like being able to see in a directory listing which files go with what. It would be unfortunate if we had to put the redundant info inside files and then hope that the info inside matched the file names and/or introduce consistency checks. A single point of truth always seems better to me than verified redundancy.
But I certainly hear your point about what happens when a new OS comes along (plan10, say) and none of the old Go releases know that foo_plan10.go should be ignored except when GOOS=plan10. If we were going to seriously consider fixing the filename-based constraint ambiguity (probably not today), there are at least three possible paths forward. 1. Remove the ambiguity by making _foo in a filename never a constraint, as you've proposed. For me, this throws the baby out with the bathwater. 2. Remove the ambiguity by making _foo in a filename *always* a constraint. If a toolchain doesn't know what foo means, then the constraint is clearly not satisfied. I think this would be too painful to deploy. I ran a scan last night and there are just far too many files using underscores for non-constraints today. 3. Two steps: 3a. Make the go command apply a list based on the go version in go.mod, so that we can say "as of Go 1.16, plan10 is a recognized GOOS". Then when building old code, any existing foo_plan10.go file doesn't get reinterpreted. 3b. Remove uncertainty in tools by making them ask the go command (perhaps using x/tools/go/packages), which always knows. I think I would lean more toward 3 than 1 or 2. As someone noted, we're certainly not going to start requiring //go:build test in every *_test.go file - that convention won't go away. But then what happens when the next thing comes along? What if for fuzzing turns out to be very helpful to have a foo_fuzz.go convention? (Probably not, but what about the next thing?) If we get all the tools asking the go command, then that kind of change is easy to deploy. (Similarly, files with import "C" only apply when the cgo tag is set. I don't think it makes sense for tools to be hard-coding that rule, nor would it make sense at this point to require an explicit //go:build cgo. If tools ask the go command instead of trying to rederive these kinds of things themselves, it's no problem at all.) I would be very interested to hear about which tools *can't* ask the go command for this info, and why, and what we can do to address that. Best, Russ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA8EjDQbwP6zsmr%2BYHw4hQbVv8c%2BkUvMAMowMb3o_%2B%3DnUu5Z2Q%40mail.gmail.com.
