FAQ

On Wednesday, June 18, 2014 12:42:48 PM UTC-7, rsc wrote:
golang.org/s/go14internal
comments welcome on this mail thread. thanks.
Just throwing out another possibility since it doesn't seem to have been
discussed yet:

1. Declare that "internal" packages within $GOROOT are exempt from the Go 1
guarantee. No such packages currently exist, so this is backwards
compatible with the current guarantee.
2. Have "go vet" warn about code that uses "internal" packages that resolve
into $GOROOT.
3. Maybe have "go doc" hide "internal" packages by default (e.g., for
golang.org/pkg), and even when showing them put obvious warnings that the
packages aren't covered by the compat guarantee.

Upside would be it's still *possible* to write code making use of Go
internals when necessary, but end users shouldn't be surprised if their
code is broken by upstream changes. Though I can appreciate that's
probably a niche use case when weighed against the risk of users depending
on internals even after extensive warnings not to.

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

  • Andrew Gerrand at Jul 15, 2014 at 11:44 pm

    On 16 July 2014 09:39, Matthew Dempsky wrote:

    Just throwing out another possibility since it doesn't seem to have been
    discussed yet:

    1. Declare that "internal" packages within $GOROOT are exempt from the Go
    1 guarantee. No such packages currently exist, so this is backwards
    compatible with the current guarantee.
    2. Have "go vet" warn about code that uses "internal" packages that
    resolve into $GOROOT.
    3. Maybe have "go doc" hide "internal" packages by default (e.g., for
    golang.org/pkg), and even when showing them put obvious warnings that the
    packages aren't covered by the compat guarantee.

    Upside would be it's still *possible* to write code making use of Go
    internals when necessary, but end users shouldn't be surprised if their
    code is broken by upstream changes. Though I can appreciate that's
    probably a niche use case when weighed against the risk of users depending
    on internals even after extensive warnings not to.
    I'm pretty sure this has been covered already, but I don't blame you for
    not having noticed (the thread is >150 posts deep at this point).

    If people want to use those packages they can just fork them. That's an
    extremely low barrier to entry, particular for people who are comfortable
    grubbing around in the internals of the compiler etc.

    --
    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.
  • Matthew Dempsky at Jul 15, 2014 at 11:47 pm

    On Tue, Jul 15, 2014 at 4:43 PM, Andrew Gerrand wrote:

    I'm pretty sure this has been covered already, but I don't blame you for
    not having noticed (the thread is >150 posts deep at this point).
    Yeah, I was reading the thread from Google Groups and didn't notice it
    spanned multiple pages until right after clicking Post. Sorry about that.
    :(

    --
    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
postedJul 15, '14 at 11:39p
activeJul 15, '14 at 11:47p
posts3
users2
websitegolang.org

2 users in discussion

Matthew Dempsky: 2 posts Andrew Gerrand: 1 post

People

Translate

site design / logo © 2021 Grokbase