What compatibility of go/ast, go/types, go/packages packages is planned, if any, when transitioning toward go2 ?

[clément auger]

Hello,

I am wondering if some backward compatibility is planned for programs heavily relying

on ast, parser, type, packages packages to analyze, interpret, manipulate go source code.

I read this morning the blog and it says

'The language changes are fully backward compatible' in its last news on this topic,

does it apply to this case ?

I am wondering the same question about the reflect package.

I wonder at which extent it will have to be modified to welcome this new feature.

I am asking those questions partly because i hope I will be able to transition without work, tbh, though maybe it wont be possible ?

In any cases, can I already read the new implementation somewhere or is it too soon ?

thank you for reading.

[Axel Wagner]

Programs written against a current Go version should continue to work indefinitely.

So, yes, if you don't want to take advantage of generics (or other Go 2 changes), you don't have to do any work to have your program continue to work. That's why I don't like the "Go 2" label - there just won't be a traditional compatibility break (most likely).

There is, of course, one caveat: Any observable change in behavior can be made "breaking", by writing a program that a) observes the behavior, b) does nothing under the current behavior and c) panics under the new. That is, you can write a program that, for example, passes a go program using generics to go/types and panics *if that compiles*. Then, technically, that program breaks once we introduce generics.

But I think apart from artificial situations like that, any reasonable program can be reasonably assumed to continue working as before.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/148f99b9-1e1a-4d0a-a3d2-44ac068bf230n%40googlegroups.com.

[Ian Lance Taylor]

On Wed, Jan 27, 2021 at 1:10 PM clément auger <clement...@gmail.com> wrote:
>
> I am wondering if some backward compatibility is planned for programs heavily relying
> on ast, parser, type, packages packages to analyze, interpret, manipulate go source code.
>
> I read this morning the blog and it says
> 'The language changes are fully backward compatible' in its last news on this topic,
> does it apply to this case ?
>
> I am wondering the same question about the reflect package.
> I wonder at which extent it will have to be modified to welcome this new feature.
>
> I am asking those questions partly because i hope I will be able to transition without work, tbh, though maybe it wont be possible ?

To be clear, there is no Go 2, and there are no plans for Go 2.

I assume you are referring to adding generics to the language. If
that proposal is adopted, then necessarily the go/ast and related
packages will have to change. The changes will only be additions, and
those additions will only be used if working with a program that uses
type parameters. This means that some programs that manipulate Go
code will have to change to support manipulating Go code with
generics. And some programs will continue to work unchanged. The
same is true for any language change, but of course generics touches
many more parts of the language.

The reflect package is largely unaffected by the generics proposal.
See https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#reflection.

> In any cases, can I already read the new implementation somewhere or is it too soon ?

You can see preliminary versions of the changes to go/ast and related
packages on the dev.typeparams branch of the main Go repo. That is a
development branch being used to try out generics before the proposal
is accepted (if the proposal is accepted). As a development branch it
is not covered by any sort of stability guarantee and can change at
any time.

Ian

[Carla Pfaff]

On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:

To be clear, there is no Go 2, and there are no plans for Go 2.

For someone who follows the mailing lists and issue comments this has been known for a while, but it's easy to see where the confusion comes from, given these blog posts:

https://blog.golang.org/toward-go2

https://blog.golang.org/go2-here-we-come

https://blog.golang.org/go2-next-steps

They mention backward-compatibility, but only for the initial proposals "to get the ball rolling". There hasn't been a blog post titled "There are no plans for Go 2" or "Go 2 is not what you think it is" so far. The current policy seems to be this document:

"Proposal: Go 2 transition": https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md

"If the above process works as planned, then in an important sense there never will be a Go 2."

It is labeled "Proposal", but it doesn't seem to be a proposal in the usual proposal process sense, and many may have missed it.

 

[Ian Lance Taylor]

You're right, I wrote that poorly. People use "Go 2" in various
different ways. I should have said: there is no plan to ever break
backward compatibility with earlier versions of Go.

Ian

[Michael Ellis]

On Wednesday, 27 January 2021 at 23:28:17 UTC+1 Ian Lance Taylor wrote:

To be clear, there is no Go 2, and there are no plans for Go 2.

Speaking as one who suffered through the ill-conceived and interminable Python3 transition, this is the best news I've heard since discovering and falling in love (well, it is Valentines Day) with Go a couple of years ago.  Thank you!