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.


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 

Reply via email to