My suggestion was a variation on rsc's #2. Still a simple rule that is easy for people to remember and doesn't require asking the go command. Prefer a simple rule compared to any intermediation by a program.
> On Jul 1, 2020, at 11:54 AM, jimmy frasche <soapboxcic...@gmail.com> wrote: > > Running find -name "*_*.go" | xargs grep " +build" on goroot shows a > lot of files with redundant build tags or additional constraints not > present in the file name so they don't seem like much of a single > point of truth. > > I'd be fine with removing file names sometimes implying build tags. > Add build tags from the filename to the go:build line and after go1.X > stop getting build tags from the file name. > > There would still be special cases like _test and cgo but there would > be fewer special cases. Option 3 looks like a solid plan to handle the > hypothetical _fuzz even if otherwise things converge on go:build. > > On Wed, Jul 1, 2020 at 11:20 AM Bakul Shah <ba...@iitbombay.org> wrote: >> >> 4. Use two underscores for constraints. At least new constraints. >> >> Aside: Are you plantin' an idea about Plan10? >> >> On Jul 1, 2020, at 11:06 AM, Russ Cox <r...@golang.org> wrote: >> >> 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. >> >> >> -- >> 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/443ACF21-0A34-484D-B1E3-273E6226E96C%40iitbombay.org. -- 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/E2A8C218-6ACD-4355-ACEF-D42FB1F2F94B%40iitbombay.org.
