flag: Args() should return the non-flag arguments regardless of their position relative to the flag arguments

[DrGo]

What did you do?

See https://play.golang.org/p/VOZki0Q4Vmc
Command line arguments are not parsed correctly (at least not according to the documentation) when the non-flag arguments are provided before the flag arguments.

What did you expect to see?

The printout from fmt.Printf("argument passed: %s; Flags passed: %s", flag.Args(), *flgPtr) should be
argument passed: [AnArgument]; Flags passed: AFlag

What did you see instead?

argument passed: [AnArgument -t AFlag]; Flags passed:

System details

go version go1.10 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/salah/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/salah/Dropbox/code/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kz/fc7nstbx16q2gvb1w6rry8cm0000gn/T/go-build532066519=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.10 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.10
uname -v: Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D102
lldb --version: lldb-360.1.70

[dgryski]

The documentation for the flag package says

Flag parsing stops just before the first non-flag argument ("-" is a non-flag argument) or after the terminator "--".

In your case, AnArgument is a non-flag argument and so parsing stops before it reaches -t.

[DrGo]

Sorry, I missed that line.
But, I still think the flag package should handle arguments specified before the flag because in most instances users expect to be able to specify the typically more important argument(s) before the flag.
eg,
find myfile -i
rather than
find -i myfile

[robpike]

The flag package is well-defined and simple, and in this case is working as intended, and the same as traditional Unix tools - try ls file -l. If you want different behavior, there are alternate flag-handling packages to try.