Comment 1:

(That is, wait until closer to the release to decide.)

Comment 2:

It will stay but will not be part of the initial Go 1.1 release. The API is complex and
not used enough yet to provide the necessary level of confidence.

Labels changed: removed go1.1.

Status changed to LongTerm.

Comment 3:

What does it mean to stay but not be part of Go 1.1?
The dist tool will have to be updated to delete it from the tree when
preparing the release.

Comment 4:

It means that tools that depend on it will have to be released in a version that does
not have the dependency. The dist tool will need to exclude it, yes, and vet will need
to be patched to an earlier rev.

Comment 5:

Special casing this is going to be a significant burden on the distribution
code: it's going to be mostly untested and break when we try to do the
actual distribution. I'd much rather find a mechanism that doesn't require
last-minute tweaking of the tree.
Here is an alternative:
1. Move go/types to the go.exp subrepo.
2. Arrange so that cmd/vet has all its references to go/types in one file
that can be dropped from the build. Mark that file with // +build gotypes.
3. People who want the typed vet run 'go install -tags gotypes cmd/vet'.
It also gives people who have Go 1.1 and want to try go/types a way to do
so.
Russ

Comment 6:

(3) of course requires fixing issue #4443, which is marked to be fixed anyway.

Comment 7:

And people can run 'go install -a -tags gotypes cmd/vet' until it is fixed.

Comment 8:

Labels changed: added go1.1.

Comment 9:

Just for the record:
1) The main reason for excluding it from Go 1.1 is that we might find issues that
require the API to change in non-compatible ways.
2) There's another alternative: Allow it in Go 1.1 but permit its API to change if
necessary (with a big disclaimer in the file, of course). I think that would actually be
the easiest from a release and testing point of view. There is a danger of setting an
unfortunate precedent.

Labels changed: removed go1.1.

Comment 10:

Re-adding Go 1.1 label. The label does not mean go/types is in Go 1.1. It means this is
something we need to resolve before Go 1.1.

Labels changed: added go1.1.

Comment 11:

i'd already added the label. well, it's there now, so that's ok.

Comment 12:

move go/types to cmd/vet/gotype
so that it's in Go 1.1 but excluded from API freeze?
we add those warnings, but people are free to use it
if they want.

Comment 13:

You could include it in Go 1.1, but make main sign a disclaimer that they know it's
experimental:
package main
import (
  "go/exp"  // a new package
  "github.com/bob/foo"  // which itself imports go/types, included in Go 1.1
)
func main() {
   // Enable the experimental go/types API.  The Enable call only
   // works from main.main.  If go/types is used without being enabled,
   // it panics.
   exp.Enable("go/types")
   foo.Something() // ... which uses go/types. But foo can't Enable itself. Only main can.
}
By making main declare that, it prevents:
  user A's main -> user B's foo -> go/types 1.1 (works)
  user A's main -> user B's foo -> go/types 1.2 (explodes)
... and surprising user A, who didn't know how user B's foo was implemented.

Comment 14:

https://golang.org/cl/7528044 adds -tags gotypes to the build, so vet's
conditional compilation is configured to use go/types. Remove before Go 1.1

Comment 15:

My understanding is that we're close to being able to move go/types into go.exp/types.

Comment 16:

Correct. There's a pending CL 7432051 which I am waiting for review. Once it's in, I
have no open files in go/types and we can move it.

Comment 17:

This issue was closed by revision golang/exp@38d2410.

Status changed to Fixed.

Comment 18:

Not quite, http://build.golang.org/log/f53103ff945e8849d8182ff1f61a1db75f709f90

Comment 19:

pending CL: 7554044