Besides what has been said, another use for the package declaration is being able to declare "main" programs that are ignored at build time but used by go generate within the package.
A good example of this is in the gob package: https://golang.org/src/encoding/gob/dec_helpers.go is generated by running https://golang.org/src/encoding/gob/decgen.go invoked by go generate in https://golang.org/src/encoding/gob/decode.go. Le samedi 18 mars 2017 12:49:57 UTC+1, Sunder Rajan Swaminathan a écrit : > > Before anyone flames, I love Go! There. Ok, now to the issue at hand -- > > The toolchain already seems to understand the directory layout then why > bother littering the sources with package declaration? Also is there a > point to specifying imports at a file level? I mean doesn't the linker > bring in symbols at a package level anyway? My reason for brining this up > is I'm trying to generate a codebase using a custom built specification and > having to constantly tweak the imports and packages (in over 200 files) are > getting in my way of a smooth development. I'm sure others have had the > same problem. > > In the spirit of brining a solution and not just a problem, how about the > toolchain assume a package to be "main" if there's a main function therein. > Imports could be specified at the package level like in D or Rust in a > separate file. > > Thanks! > -- 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. For more options, visit https://groups.google.com/d/optout.
