proposal: flag: Add flag.File, flag.FileVar

[earthboundkid]

It is very common to want to have a command line option that takes a file name, for example the name of a log file to create or an input to read (and this typically defaults to standard in). To achieve this in current versions of Go, one typically creates a flag.String and then checks whether the value is "" or "-" and if not opens *os.File.

I propose to add flag.File and flag.FileVar to the flag package. It will attempt to open the passed in file name at flag.Parse() time and on failure print an error message and exit.

If this proposal is accepted, I can create a CL.

[ghost]

It is unlikely that this proposal will be accepted, as the flag package isn't adding any more features (in Go1) (see #23013).

[ianlancetaylor]

It should be possible to write such a flag in a third party package. It shouldn't be necessary to add it to the flag package in the standard library. So the first step might be to write that third party package and see how many places could use it.

[as]

If it typically defaults to standard input, why not assign the file to os.Stdin? I personally dont like the idea of opening files in the flags package because theres no elegant way I know of to close them with a defer.

[mvdan]

One reason I see against adding this to the flag package is how subtle this type would be. All the existing types, such as String and Int, are immediately obvious.

However, when it comes to File, a number of questions come up. What should happen when it is given a directory? Would it always open files via os.Open? What if one needed other modes, such as opening a file for writing? And there's always the controlling of how and when Close is called, as @as mentioned.

Doing this via a string flag and controlling all these aspects in a few lines of code seems to me like an approach that already works now. Writing a library that would let you control all these aspects is possible, but its API would be much heavier than that of the existing package.

[rsc]

Note that you can write your own implementations of the flag.Value interface, so if you have specific semantics you want around this flag, and it's common enough in your code, then you can implement your own FileFlag in your own library and use it. It doesn't need to be in the standard library.

It's too specialized, and there are too many details we'd need to expose user control over, to add to the standard library.