The spec does preclude that since there must be a `package main`.
https://golang.org/ref/spec#Program_execution
On Wed, 2017-10-25 at 05:02 +0000, Alex Buchanan wrote:
> Interesting, thanks. Let me try to clarify my idea with some simple
> code:
>
> // file lives at github.com/buchanae/foobar/foobar.go
> package foobar
>
> func Foobar() string {
> return "foobar"
> }
>
> func main() {
> print(Foobar())
> }
>
> This file exports both a function to be used as a library, and a main
> function which would be compiled into a command line utility. In
> order to use the library, you'd write `import
> "github.com/buchanae/foobar"; foobar.Foobar()`. In order to use the
> command line tool, you'd run `go get github.com/buchanae/foobar` and
> run `foobar` on the command line. There's no `import "main"` or
> package named main in this example. The compiler would need to look
> for a main function in the starting package and perhaps name symbols
> using the fully qualified package name. Also, packages in the
> "foobar" tree would not be importing the root, so there are no import
> cycles.
>
> I'm not sure it's a good idea, but it was my instinct when I started
> writing Go, and feels like it would have simplified the organization
> and documentation of some projects which have a separate "go get
> <url>" for the library vs the CLI command.
>
> Hope that made sense. Probably too late to be writing about such
> things :)
>
--
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.
