FWIW, I *like* the filename-based constraints. I can look at the source for the OS package (https://golang.org/src/os/) and immediately go to the _windows.go files to see how they do things on Windows (for example). It's really obvious from the directory listing, and I don't have to dig into the files to see what the build constraint is.
Then again, if Go got rid of filename-based constraints, people could still name their files like that for visibility purposes, but the actual build constraint would be in "// +build" or "//go:build" rules in the file itself. -Ben One thing I'd really like to see is the eventual deprecation of >>> filename-based build constraints (e.g. file_linux.go). >>> They make it hard for users (not everyone knows the name of all >>> architectures), hard for tooling (tools >>> need to maintain a list of current architectures) and potentially >>> compatibility-breaking (adding >>> a new architecture can change the meaning of existing files). Could we >>> eventually mandate >>> in-file build constraints instead? >>> >> -- 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/82154e18-c273-4969-8a8c-f7a04dda5109n%40googlegroups.com.
