FAQ
If you don't use x/tools/go/types or dependent packages you can stop
reading.

A few weeks back, the Go team has decided that the go/types
<https://goto.google.com/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
<https://goto.google.com/types> so it builds and tests independently of the
tools repo.)

There are several dependencies on go/types <https://goto.google.com/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> and 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 <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Apr 8, 2015 at 6:48 am
    Will you be keeping or deleting the x/tools version?

    On Wed, Apr 8, 2015 at 12:38 AM, 'Robert Griesemer' via golang-dev wrote:

    If you don't use x/tools/go/types or dependent packages you can stop
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types <https://goto.google.com/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> and 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 <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Griesemer at Apr 8, 2015 at 3:51 pm
    The x/tools version will go away, once we have rewired all its clients.
    - gri
    On Tue, Apr 7, 2015 at 11:48 PM, Brad Fitzpatrick wrote:

    Will you be keeping or deleting the x/tools version?


    On Wed, Apr 8, 2015 at 12:38 AM, 'Robert Griesemer' via golang-dev <
    golang-dev@googlegroups.com> wrote:
    If you don't use x/tools/go/types or dependent packages you can stop
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Apr 8, 2015 at 4:00 pm
    Seems unnecessarily cruel and against the spirit of API stability, even in
    x/*.

    I would update its godoc to say that it's deprecated and state the new
    location and then never update it (bug fixes only go to std), and let
    people move on their own, at their own pace.


    On Wed, Apr 8, 2015 at 5:51 PM, Robert Griesemer wrote:

    The x/tools version will go away, once we have rewired all its clients.
    - gri
    On Tue, Apr 7, 2015 at 11:48 PM, Brad Fitzpatrick wrote:

    Will you be keeping or deleting the x/tools version?


    On Wed, Apr 8, 2015 at 12:38 AM, 'Robert Griesemer' via golang-dev <
    golang-dev@googlegroups.com> wrote:
    If you don't use x/tools/go/types or dependent packages you can stop
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Griesemer at Apr 8, 2015 at 4:05 pm
    Fair point. I think we would want to move at least our x/tools/go/types
    dependencies to std repo go/types.
    - gri
    On Wed, Apr 8, 2015 at 9:00 AM, Brad Fitzpatrick wrote:

    Seems unnecessarily cruel and against the spirit of API stability, even in
    x/*.

    I would update its godoc to say that it's deprecated and state the new
    location and then never update it (bug fixes only go to std), and let
    people move on their own, at their own pace.


    On Wed, Apr 8, 2015 at 5:51 PM, Robert Griesemer wrote:

    The x/tools version will go away, once we have rewired all its clients.
    - gri

    On Tue, Apr 7, 2015 at 11:48 PM, Brad Fitzpatrick <bradfitz@golang.org>
    wrote:
    Will you be keeping or deleting the x/tools version?


    On Wed, Apr 8, 2015 at 12:38 AM, 'Robert Griesemer' via golang-dev <
    golang-dev@googlegroups.com> wrote:
    If you don't use x/tools/go/types or dependent packages you can stop
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently
    of the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Apr 8, 2015 at 4:10 pm

    On Wed, Apr 8, 2015 at 6:05 PM, Robert Griesemer wrote:

    Fair point. I think we would want to move at least our x/tools/go/types
    dependencies to std repo go/types.
    If/when you're prepared to require Go 1.5.

    Historically we've gone out of our way a few times to support older Go
    releases.

    We need a policy on our x/ repos about the supported Go version(s). Is
    vendoring the answering for Go 1.n-1 users? I want to see that addressed
    somewhere prominently in the x/* docs (x/tools/README + godoc of packages?)
    before potentially breaking people.

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Apr 8, 2015 at 5:33 pm

    On Wed, Apr 8, 2015 at 12:09 PM, Brad Fitzpatrick wrote:
    On Wed, Apr 8, 2015 at 6:05 PM, Robert Griesemer wrote:

    Fair point. I think we would want to move at least our x/tools/go/types
    dependencies to std repo go/types.
    If/when you're prepared to require Go 1.5.

    Historically we've gone out of our way a few times to support older Go
    releases.

    We need a policy on our x/ repos about the supported Go version(s). Is
    vendoring the answering for Go 1.n-1 users? I want to see that addressed
    somewhere prominently in the x/* docs (x/tools/README + godoc of packages?)
    before potentially breaking people.
    First we need to actually fix vendoring, meaning we need to nail down the
    vendoring file format and get the tools to support it well. Let's
    definitely do that before deleting x/types.

    Russ

    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Elliott Stoneham at Apr 8, 2015 at 6:55 pm
    Speaking as a person who has code <https://github.com/tardisgo/tardisgo>
    which will potentially be broken by this change, it is not the move of
    location that worries me, it is the potential change of functionality as
    part of that move (quote: "I am planning minor cleanups of the API, and
    possibly remove questionable entry points...").

    My code uses "golang.org/x/tools/go/types" alongside
    "golang.org/x/tools/go/ssa" and other related packages. It is therefore not
    possible, without significant extra work, for me to simply test a new
    version of go/types in isolation, unconnected to the other packages.

    A better approach from my point-of-view would be for the new version of
    go/types to be upgraded in the x/ repo, rework any referring code as
    required, then when all is stable, move the new version to the new location.
    On Wednesday, 8 April 2015 17:10:02 UTC+1, Brad Fitzpatrick wrote:



    On Wed, Apr 8, 2015 at 6:05 PM, Robert Griesemer <g...@google.com
    <javascript:>> wrote:
    Fair point. I think we would want to move at least our x/tools/go/types
    dependencies to std repo go/types.
    If/when you're prepared to require Go 1.5.

    Historically we've gone out of our way a few times to support older Go
    releases.

    We need a policy on our x/ repos about the supported Go version(s). Is
    vendoring the answering for Go 1.n-1 users? I want to see that addressed
    somewhere prominently in the x/* docs (x/tools/README + godoc of packages?)
    before potentially breaking people.


    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Griesemer at Apr 8, 2015 at 4:54 pm
    Thanks for bringing up this point - it has been raised internally as well.

    We will not remove x/tools/go/types for 1.5 as it would surely break many
    clients that we don't know about.

    We are looking into updating the related packages (ssa, etc.) to use the
    std repo version, but they will have to move all together (or not move for
    now) as otherwise interplay would fail.

    - gri
    On Wed, Apr 8, 2015 at 9:45 AM, wrote:

    Speaking as a person who has code <https://github.com/tardisgo/tardisgo>
    which will potentially be broken by this change, it is not the move of
    location that worries me, it is the potential change of functionality as
    part of that move (quote: "I am planning minor cleanups of the API, and
    possibly remove questionable entry points...").

    My code uses "golang.org/x/tools/go/types" alongside "
    golang.org/x/tools/go/ssa" and other related packages. It is therefore
    not possible, without significant extra work, for me to simply test a new
    version of go/types <https://goto.google.com/types> in isolation,
    unconnected to the other packages.

    A better approach from my point-of-view would be for the new version of
    go/types <https://goto.google.com/types> to be upgraded in the x/ repo,
    rework any referring code as required, then when all is stable, move the
    new version to the new location.
    On Wednesday, 8 April 2015 17:10:02 UTC+1, Brad Fitzpatrick wrote:


    On Wed, Apr 8, 2015 at 6:05 PM, Robert Griesemer wrote:

    Fair point. I think we would want to move at least our x/tools/go/types
    dependencies to std repo go/types <https://goto.google.com/types>.
    If/when you're prepared to require Go 1.5.

    Historically we've gone out of our way a few times to support older Go
    releases.

    We need a policy on our x/ repos about the supported Go version(s). Is
    vendoring the answering for Go 1.n-1 users? I want to see that addressed
    somewhere prominently in the x/* docs (x/tools/README + godoc of packages?)
    before potentially breaking people.


    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Apr 8, 2015 at 6:56 am
    Excellent news. I've been wanting this for ages.

    On Wed, Apr 8, 2015 at 8:38 AM, 'Robert Griesemer' via golang-dev
    wrote:
    If you don't use x/tools/go/types or dependent packages you can stop
    reading.

    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 and 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 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 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 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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Markus Zimmermann at Apr 9, 2015 at 10:15 am
    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? 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
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types <https://goto.google.com/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> and 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 <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Griesemer at Apr 9, 2015 at 8:57 pm
    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
    conservative here.

    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.
    - gri

    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
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Zellyn at Apr 9, 2015 at 11:05 pm
    I'm confused: it seems that you're describing changes you want/intend to
    make, *and* proposing moving it to a place where the compatibility
    guarantee prevents those changes. I expect I'm misunderstanding something.

    Zellyn
    On Thursday, April 9, 2015 at 1:57:17 PM UTC-7, Robert Griesemer wrote:

    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
    conservative here.

    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.
    - gri


    On Thu, Apr 9, 2015 at 3:14 AM, Markus Zimmermann <zim...@gmail.com
    <javascript:>> 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
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently of
    the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Robert Griesemer at Apr 9, 2015 at 11:08 pm
    I _may_ clean up (i.e., remove) methods from the API that are not
    absolutely required, by 1.5, to keep the API that cannot be changed
    smaller. We _may_ also ending up leaving it alone.
    - gri
    On Thu, Apr 9, 2015 at 4:05 PM, wrote:

    I'm confused: it seems that you're describing changes you want/intend to
    make, *and* proposing moving it to a place where the compatibility
    guarantee prevents those changes. I expect I'm misunderstanding something.

    Zellyn
    On Thursday, April 9, 2015 at 1:57:17 PM UTC-7, Robert Griesemer wrote:

    Apologies for being vague.

    A long-standing TODO was to "clean up" the go/types
    <https://goto.google.com/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
    <https://goto.google.com/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 <https://goto.google.com/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
    <https://goto.google.com/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
    <https://goto.google.com/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 conservative here.

    We have a strong interest in maintaining go/types
    <https://goto.google.com/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.
    - gri


    On Thu, Apr 9, 2015 at 3:14 AM, Markus Zimmermann <zim...@gmail.com>
    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
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently
    of the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Zellyn Hunter at Apr 9, 2015 at 11:33 pm
    Ah, that makes sense. Thanks! :-)
    On Thu, Apr 9, 2015 at 4:08 PM Robert Griesemer wrote:

    I _may_ clean up (i.e., remove) methods from the API that are not
    absolutely required, by 1.5, to keep the API that cannot be changed
    smaller. We _may_ also ending up leaving it alone.
    - gri
    On Thu, Apr 9, 2015 at 4:05 PM, wrote:

    I'm confused: it seems that you're describing changes you want/intend to
    make, *and* proposing moving it to a place where the compatibility
    guarantee prevents those changes. I expect I'm misunderstanding something.

    Zellyn
    On Thursday, April 9, 2015 at 1:57:17 PM UTC-7, Robert Griesemer wrote:

    Apologies for being vague.

    A long-standing TODO was to "clean up" the go/types
    <https://goto.google.com/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
    <https://goto.google.com/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 <https://goto.google.com/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
    <https://goto.google.com/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
    <https://goto.google.com/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 conservative here.

    We have a strong interest in maintaining go/types
    <https://goto.google.com/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.
    - gri


    On Thu, Apr 9, 2015 at 3:14 AM, Markus Zimmermann <zim...@gmail.com>
    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
    reading.

    A few weeks back, the Go team has decided that the go/types
    <https://goto.google.com/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
    <https://goto.google.com/types> so it builds and tests independently
    of the tools repo.)

    There are several dependencies on go/types
    <https://goto.google.com/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> and
    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
    <https://goto.google.com/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 golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 7, '15 at 10:38p
activeApr 9, '15 at 11:33p
posts15
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase