Context package and go 1.7

[vadimi]

Considering that context package is now a part of the standard library does it make sense to use context in generated files instead of golang.org/x/net/context for go 1.7?

[broady]

Not yet. Probably not for a while. People still need to support 1.6 and maybe even 1.5.

[vadimi]

That makes sense, thanks. Considering that golang.org/x/net/context for go 1.7 uses native context that shouldn't be a big deal.

[puellanivis]

This issue was discussed on the gRPC side, and I've worked on this issue myself. (Since I am being a bleeding edge adopter.)

There is no good solution that is adequate that would allow one to compile the same code with 1.6 and 1.7 without massive amounts of hacky work around. Even just using "context" for 1.7, but not for anything earlier doesn't work, as again, code needs to be 1.6 and 1.7 ambi-compilable.

The main golang branch has had a proposal around this which would allow identical interfaces to be treated as identical types regardless of naming, but this could possibly break some very esoteric code, and as such, likely will not make it into Go before this issue becomes moot. (i.e. once 1.6 goes out of support.)