The implementation has no special handling for dotfiles so in case 3 it thinks the entire filename denotes an extension with the actual name part being blank.

That's good design in my books. Less special cases are better. The definition of what a file extension is can then stay simple and that's desirable.

I agree that the behavior is somewhat confusing if you're used to modern unix-like systems, which make heavy use of dotfiles. However, I think it's also worth pointing out that dotfiles are not special at all on some systems such as Windows, as they have a completely different definition of hidden files.

With that in mind, I'm not sure it's a good idea for these APIs to handle dotfiles. For example, what should path.Ext(".exe") do on Windows? There can be multiple answers to that question, but I think they all add complexity to Ext.

Playing my own devil's advocate - you could also argue that this isn't about dotfiles, but about filename extensions being a suffix to a non-empty name. That depends on how systems like Windows initerpret filenames like .exe - is it a file with name .exe and no extension, or a file with no name and .exe extension?

Considering that the concept of a file name extension is defined right there in the path.Ext docs, I think the current behaviour is fine and can't be changed anyway (for Go 1, at least).

The extension is the suffix beginning at the final dot in the final slash-separated element of path; it is empty if there is no dot.

Yeah, we can't chnnge this for Go 1, so this is by definition a Go 2 proposal.

But I believe enough people on the Go team view dotfiles as horrible that I don't imagine they'd get much if any special support.

The current path.Ext function is simple, and this proposal would make it slightly more complex. If you want to handle dot files specially, it's trivial to write your own function. We don't need to change the standard one.