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

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.

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.

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.

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.