how to prevent go1.13 go directive being written in an go directive-free go.mod?

[Dan Kortschak]

The semantics of this line of go.mod is not described anywhere, but the
tool chain blithely writes it to a go.mod file when there is no go
directive present.

Is there a way to mark the go.mod as go version-agnostic?

[Ian Lance Taylor]

No. But there is no particular reason to do so.

The semantics, such as they are, are documented at
https://golang.org/cmd/go/#hdr-The_go_mod_file: it's "the expected
language version." It sets the -lang option passed to cmd/compile,
documented at https://golang.org/cmd/compile/.

You can write your own Go directive if you like, and it won't be
modified. You can also set it programatically using `go mod edit
-go=version`.

Ian

[Dan Kortschak]

The semantics of the directive are not defined, and there are comments
like this[1] that would introduce breakage for people who target more
than one version of Go.

Which version do we choose to write? Gonum support latest and two
previous versions. We have had to write go 1.10 into that line so that
the tests against master don't fail, but this is another line that we
have to edit we we adjust versions for testing. When it becomes
important, I'd be happy to write it down, but the absence of any
semantic definition, it's just another line of text that has an
expected syntax, but no other apparent value.

[1]https://github.com/golang/go/issues/30791#issuecomment-472431458

[Ian Lance Taylor]

On Mon, Jun 10, 2019 at 10:51 PM Dan Kortschak <d...@kortschak.io> wrote:
>
> The semantics of the directive are not defined, and there are comments
> like this[1] that would introduce breakage for people who target more
> than one version of Go.

Yes. A good reason to not do that. We don't do it today, and there
are no plans to do it.

> Which version do we choose to write? Gonum support latest and two
> previous versions. We have had to write go 1.10 into that line so that
> the tests against master don't fail, but this is another line that we
> have to edit we we adjust versions for testing. When it becomes
> important, I'd be happy to write it down, but the absence of any
> semantic definition, it's just another line of text that has an
> expected syntax, but no other apparent value.

Why do you think you would ever have to change the value go1.10?

Ian

[Ian Lance Taylor]

That was perhaps a bit terse. Let me add: the clearest description of
the use of the go directive is at
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
.

Ian

[Ian Davis]

https://golang.org/cmd/go/#hdr-The_go_mod_file documents the go directive as the "expected language version". It seems it would be better described there as the "minimum language version".

> --
> 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/CAOyqgcWoaZkRFvLAUpyMaAo-L5TfZRmOR%3DfEo-U3cEHQ3qNPtg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[t hepudds]

As far as I understand, it is not a minimum version of the language.

Also, a key point that is easy to miss is that the language version is distinct from tooling version, and newer tooling versions will know how to compile older language versions. At least, that is my understanding, though I am also aware there is some confusion on the topic, so I don’t fully trust my understanding.

Some related text from the document Ian cited:

———————
The Go compiler released with Go version 1.20 must be able to build packages using Go language 1.19. This can be done by adding an option to cmd/compile [...]. When cmd/compile sees the option, perhaps -lang=go1.19, it will compile the code using the Go 1.19 syntax.

Importantly, specifying the maximum version of the Go language should not be taken to imply the maximum version of the Go tools.

[...]

When cmd/compile sees the option, perhaps -lang=go1.19, it will compile the code using the Go 1.19 syntax.
This requires cmd/compile to support all previous versions, one way or another.

[...]

Naturally, even though the package is built with the language version 1.19 syntax, it must in other respects be a 1.20 package: it must link with 1.20 code, be able to call and be called by 1.20 code, and so forth.

The go tool will need to know the maximum language version so that it knows how to invoke cmd/compile. Assuming we continue with the modules experiment, the logical place for this information is the go.mod file. The go.mod file for a module M can specify the maximum language version for the packages that it defines
——————

Regards,
thepudds

[Ian Davis]

Yes, I wrote minimum when I meant to write maximum! Sorry for the confusion.

> --
> 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/810a1cb4-c3fb-4b2f-bc86-02793902d422%40googlegroups.com.

[Dan Kortschak]

Thanks, Ian.

Comments in-line.

On Tue, 2019-06-11 at 06:42 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:40 AM Ian Lance Taylor <ia...@golang.org>
> wrote:
> >
> > On Mon, Jun 10, 2019 at 10:51 PM Dan Kortschak <d...@kortschak.io>
> > wrote:
> > >
> > > The semantics of the directive are not defined, and there are
> > > comments
> > > like this[1] that would introduce breakage for people who target
> > > more
> > > than one version of Go.
> >
> > Yes. A good reason to not do that. We don't do it today, and
> > there
> > are no plans to do it.

However it was suggested by a googler who is apparently reasonably
involved in the implementation of modules judging by the issues they
are respond to and CLs they send. In the absence of any comments to the
commentary (now here, thanks), this would lend some credence to the
idea that it would happen.

> >
> > > Which version do we choose to write? Gonum support latest and two
> > > previous versions. We have had to write go 1.10 into that line so
> > > that
> > > the tests against master don't fail, but this is another line
> > > that we
> > > have to edit we we adjust versions for testing. When it becomes
> > > important, I'd be happy to write it down, but the absence of any
> > > semantic definition, it's just another line of text that has an
> > > expected syntax, but no other apparent value.
> >
> > Why do you think you would ever have to change the value go1.10?
>
> That was perhaps a bit terse. Let me add: the clearest description
> of
> the use of the go directive is at
>
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
> .
>

I've just had a look through that again, and I come away little better
informed about what it means in this situation. There are two sections
that talk about it: "Language removals" and "Language additions". The
first describes it as a maximum version (which suggests that we should
not have it at 1.10, but rather 1.12 at the moment - noting well that
the maximum version does not state what will build but what language
features are available), and the latter talks about minimum versions
although this is described as optional.

It would be very nice if the documentation and clarity of communication
around this were improved.

thanks
Dan

[Ian Lance Taylor]

On Tue, Jun 11, 2019 at 4:53 PM Dan Kortschak <d...@kortschak.io> wrote:
>
> It would be very nice if the documentation and clarity of communication
> around this were improved.

I struggle with what to say beyond "it sets the language version."
Language features available as of that version will be available for
use. Language features removed in earlier versions, or added in later
versions, will not be available. For almost all users the default
value will be correct. At least, I hope that is the case.

Ian

[Dan Kortschak]

Having that and exactly what it means in the go help modules output
would probably be the best outcome.

Currently it's not mentioned in that output for the current release
(1.12.6) and the meaning/implication of "expected [Go] language
version" is not defined in tip's version (f2a4c13).

Dan

[Ian Lance Taylor]

On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak <d...@kortschak.io> wrote:
>
> Having that and exactly what it means in the go help modules output
> would probably be the best outcome.
>
> Currently it's not mentioned in that output for the current release
> (1.12.6) and the meaning/implication of "expected [Go] language
> version" is not defined in tip's version (f2a4c13).

I sent https://golang.org/cl/18184 to add some text to "go help go.mod".

Ian

[t hepudds]

Hi Ian,

Thank you for sending that CL 181840.

One minor request for clarification on the discussion here.

When you said earlier in this thread:

> “For almost all users the default
value will be correct.  At least, I hope that is the case.”

I *think* what you are saying is for almost everyone the default value set should be a valid choice when initially selected by the 'go’ command, even though someone might later need to manually change it in the future as new language features are released?

In other words, if hypothetically something like a new 'try' keyword lands in something like Go 1.15, then at that point someone might need to change the value in their go.mod from for example 'go 1.12' to instead read 'go 1.15' if they want to use the new language feature?

Sorry if that is not correct.

Regards,
thepudds

[Dan Kortschak]

Thanks, Ian.

I'll look later today.

Dan

[Dan Kortschak]

For others, the cl is https://golang.org/cl/181840 (note the extra 0).

[Ian Lance Taylor]

Yes, that is how it works today. We will have to see how that plays
out in practice.

Ian

[Ian Lance Taylor]

On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak <d...@kortschak.io> wrote:
>
> For others, the cl is https://golang.org/cl/181840 (note the extra 0).

Thanks.

(My laptop keyboard is barely a year old and already becoming unreliable.)

Ian

[Dan Kortschak]

I feel your pain. For me it's at the other end of the keyboard.

Dan