proposal: text/template: Move text/template/parse into an internal package

[earthboundkid]

For #10608, the text/template/parse package was changed in a way that was a breaking change in 28c1ad9. The justification of this is that text/template/parse would have been an internal package if that had existed before and users shouldn't import it. I agree with that reasoning, but I think if we are going to treat text/template/parse as internal and break its API, we may as well make it internal.

My proposal is that in Go 1.11, we add documentation explaining that text/template/parse will be moved to an internal package and in 1.12, text/template/parse is moved. If we want to be more aggressive, we could move it sooner, since 1.11 is already a breaking change to anyone relying on text/template/parse.

[cznic]

I don't think #10608 was a breaking change, but this issue definitely would be one.

[kardianos]

@carlmjohnson I use the text/template parse tree. So... aside from breaking the Go1 compatibility promise which would prevent this, this is a really bad idea.

[earthboundkid]

From the CL comments:

Daniel Martí:

Sorry, I'm still not clear on whether we can break the text/template/parse API. I would generally assume not, but the package doc clearly states that it's "shared internal data structures not intended for general use", and you gave your +2, so perhaps it is.

Rob Pike:

As long as html/template still works, yes.

This will break some dependants, no doubt, but parse would be an internal package if internal packages existed when it was written. The documentation says to stay away.

I would still be happy to abandon this, but the proposal was accepted so you are free to submit.

Brad Fitz:

LGTM I guess. I didn't know we had such a volatile, internal-but-public package.

[earthboundkid]

If we want parse to follow the Go 1 guarantee, someone can go back and fix it, but as is, the guarantee is broken by token renaming.

[earthboundkid]

I think if someone introduces type VariableNode = AssignNode that would fix the breakage.

[robpike]

The doc comment suggests not to use this package at all. It was created before internal packages were available but if they were, it would have been made one.

So it's in an odd state now. It has had several breaking changes, and there may be more, because it's really not a package you should be using. But people do use it, so we can't just make it internal.

[mvdan]

Why not simply mark this issue as Go2? It seems to me like that is the right time to start hiding this package, if that's what we want.

[robpike]

It's not at all clear we can do this in Go 2 either, but we certainly can't do it in Go 1.

[Azareal]

I use it for a Go Template to Go transpiler using the same AST, I would use the other packages, however I've found that they can be fairly... slow in comparison. It's as much as 40 times faster.