No...
the doc says:
"The returned path ends in a slash only if it represents a root directory, such as "/" on Unix or C:\ on Windows."
http://golang.org/pkg/path/filepath/#Clean

See code:
http://golang.org/src/path/filepath/path.go?s=2213:2243#L71

Related discussion with more details: https://groups.google.com/forum/#!topic/golang-nuts/xFWpetTOPp4

@xiofen I am no good at writing documentation. So, if you feel strongly about it, suggest you own change - http://golang.org/doc/contribute.html

Thank you.

Alex

I agree

Perhaps "adding a separator if one is not already present"

@minux and me disagree about https://go-review.googlesource.com/#/c/11882 change. We need more reviewers to lean us one way or the other. Please help. Thank you.

Alex

Although I do think the new behaviour is better, I also think this is a breaking change. So this should be a no-go for Go1.x.

I don't see a clear justification for the change in CL 11882. I see the logic in it, but the function was never documented to work that way, and it could clearly break existing programs. I think we should document the current behavior, as this issue suggests.

Intuitively, I see filepath.Join as giving the path you would get if you did a Chdir to each path in sequence (without looking at the filesystem, so you could end up with a relative path). On Windows if I Chdir("c:") and then Chdir("abc") I end up in the same place as if I did Chdir("c:abc"). This is different from Chdir("c:\abc") because on Windows you have a working directory for each drive letter.

I don't have any valid intuition about the current behavior. It strikes me as just a symbol manipulation that makes Unix-specific assumptions even though filepath is supposed to be a cross platform module.

Although it could break existing code, I suspect any such existing code is already buggy, and this change would make it less buggy.

Thanks to everyone for their input. It seems to me I don't have support for my change. I just want to clarify my reasoning (before I abandon my change). With this code:

a := ...
b := filepath.Join(a, ...)

If "a" contains absolute path (filepath.IsAbd(a) returns true), should I expect "b" to contain absolute path?

If "a" contains relative path (filepath.IsAbd(a) returns false), should I expect "b" to contain relative path?

The answers to these questions are "yes" on unix. Not so on windows. This program http://play.golang.org/p/_DOiToc8cD prints:

a is "c:\\" and filepath.IsAbs(a) is true
b is "c:\\file.txt" and filepath.IsAbs(b) is true

a is "c:" and filepath.IsAbs(a) is false
b is "c:\\file.txt" and filepath.IsAbs(b) is true

I think that this invariant is important. If only because Go team developers (none of who use windows) assume that invariant is there. So no amount of documenting will stop them (and others) from making mistakes.

Alex

@alexbrainman To be clear, I agree with your rationale, and if we were designing this function now, that is how it should work.

But that's not the question we are facing. The question is: given that the function has behaved as it presently does since before the Go 1 release, should we change it? The current behaviour is meaningful, is not always wrong, and is easy to avoid if you know about it. Given that, it's hard for me to support a change that may silently break some currently working programs.

If the interface is like below, I agree with your opinion.

func MakePath(drive string, elems... string) string

But this is Join that mean joining the given path and path independently.

C:\dev\src\foo>go run main.go
a
c:\a

C:\dev\src\foo>

So I'm thinking this is right.

CL https://golang.org/cl/17198 mentions this issue.

CL https://golang.org/cl/17470 mentions this issue.

CL https://golang.org/cl/17620 mentions this issue.