Apologies for being vague.
A long-standing TODO was to "clean up" the go/types interface.
Specifically, there are many methods on go/types' exported types that are
only present so that those types can be constructed from importers
(types.Interface is an example). Yet, incorrectly used, those methods may
lead to violations of invariants assumed by the type-checker. Or in other
words, I'd rather not export many of these methods.
I believe there are a few other clients (besides importers) of go/types
that construct their own types from the "outside" as well. Again, this ties
down what representations that type-checker can use. I'd rather not have
that fixed (i.e. exported). The primary goal of go/types was to compute
types and values and make them accessible to a client. It was not the goal
to permit clients to construct arbitrary types and insert them into
type-checking, because that's extremely difficult to get right in general
(i.e., w/o detailed understanding of the type checker's details). The
(external) importers are the prime reason why some mechanism to do this was
required in the first place (and the importers need to know a lot about the
type-checker's data structures to create them correctly).
There's no easy way out (otherwise we'd have fixed it long ago).
Please keep in mind:
1) We won't remove x/tools/go/types for 1.5.
2) It's not clear that we are going to make significant changes (besides
perhaps better names) in the first place.
2) If we change existing x/tools clients to use the std/repo go/types, we
have to change all of them or none (otherwise they cannot interoperate).
3) It's easy to add missing pieces to the std repo go/types, but once in a
release, we cannot remove existing parts the API anymore due to the
backward compatibility guarantee for the std repo. It's better to be
We have a strong interest in maintaining go/types for the long run. We
believe it's going to be useful for a variety of tools. Moving it into the
std repo will make that easier. Simplifying the interface (if we can) will
make that easier.
It is a non-goal to support every conceivable special use-case which goes
being querying the results of type-checking packages.
Unless you explicitly depend on creating types from the outside, this may
not affect you at all.
I hope this helps.
On Thu, Apr 9, 2015 at 3:14 AM, Markus Zimmermann wrote:
Could you please elaborate. What are these clear flaws you see and what
are your cleanup plans? In general, what is the TODO and what are future
plans for go/types <https://goto.google.com/types
>? I rather help
changing things now.
On Wednesday, April 8, 2015 at 12:38:54 AM UTC+2, Robert Griesemer wrote:
If you don't use x/tools/go/types or dependent packages you can stop
A few weeks back, the Go team has decided that the go/types
> package, currently in the x/tools repo,
should move into the std repo. I have sent out an initial change last night:https://go-review.googlesource.com/8530
(At the moment, this change simply "vendors" a copy of go/types
> so it builds and tests independently of
the tools repo.)
There are several dependencies on go/types
> in the std repo that have become
increasingly cumbersome to maintain. For instance, the api checker
(src/cmd/api) depends on go/types <https://goto.google.com/types
when run it explicitly checks out an (old) version for that purpose. The
code for go vet resides in the x/tools repo (cmd/vet) yet is considered a
standard functionality of the go tool. The same is true for stringer
(cmd/stringer), which may be invoked by go generate. Other tools that might
benefit from go/types <https://goto.google.com/types
> cannot because
it's not in the same repo. Moving go/types
> into the std repo eliminates this issues.
On the other hand, making go/types <https://goto.google.com/types
> a std
package puts it under the constraints of the std repo - the API must not
change in backward-incompatible ways going forward. That said, the current
API, while clearly with flaws, has not changed in any substantial way for a
long time. Many tools have been built atop it successfully. For all
practical purposes, the API appears to be "good enough" for now. (There are
always improvements possible, but there is also always room for a version 2
should the need arise).
I am planning minor cleanups of the API, and possibly remove questionable
entry points (we can always add later, but we cannot remove after 1.5). If
you depend on go/types <https://goto.google.com/types
> and run into
problems, please comment on the relevant changes by filing issues and
assigning them to me. Thanks.
- gri, for the Go team
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.