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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/CAA8EjDQbwP6zsmr%2BYHw4hQbVv8c%2BkUvMAMowMb3o_%2B%3DnUu5Z2Q%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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.
