> Maybe it shouldn't. By my knowledge, the version specified in go.mod doesn't prevent APIs newer than the version to be used. This is design.
===== OK. It looks a Go project with version declared as 1.15 in go.mod and importing "embed" also compiles okay with Go toolchain 1.16 So the key distinction is whether there are "//go:embed" directives are used. Here, I tested four setups (all with version declared as 1.15 in go.mod and compile with Go toolechain 1.16: 1. a source file importing "io/fs". It compiles okay. 2. a source file importing "embed" but not using "//go:embed". It also compiles okay. 3. a source file importing "embed" and using "//go:embed". It fails to compile with an error "go:embed requires go1.16 or later (-lang was set to go1.15; check go.mod)" 4. a source file importing using "//go:embed" and not importing 1.16 new packages. It fails to compile with an error "usage: //go:embed pattern...". I don't know whether or not it is intended to let the latter two cases report different errors. On Tuesday, March 2, 2021 at 8:25:53 AM UTC-5 axel.wa...@googlemail.com wrote: > Maybe it shouldn't. > > FWIW, there is one significant difference, which is that `//go:embed` > needs support from the go tool and compiler to work. That is, the files > need to be read and we need to emit initialization code for the variables > holding the embedded files. So, a go toolchain that is not aware of > embedding can't possibly compile the code (correctly). > > On Tue, Mar 2, 2021 at 2:19 PM tapi...@gmail.com <tapi...@gmail.com> > wrote: > >> What is the difference between "embed" and "io/fs"? >> A Go project with version declared as 1.15 in go.mod and using "io/fs" >> compiles okay with Go toolchain 1.16. >> >> On Tuesday, March 2, 2021 at 7:50:15 AM UTC-5 axel.wa...@googlemail.com >> wrote: >> >>> Okay, sorry for the multiple, quick mails, but: >>> I would even say it *has* to be done the way it is. Because otherwise >>> compilation will *not* fail, if you declare a wrong go version to use. That >>> is, if you use `//go:embed`, declare your used version as go 1.15 and test >>> it yourself using go 1.16, your module is broken. Users of your module that >>> only have go 1.15 will break and get a crypting error message about `embed` >>> being missing, instead of a reasonable message that their go version is not >>> fresh enough. >>> I don't understand why you'd want a broken module to compile. >>> >>> On Tue, Mar 2, 2021 at 1:46 PM Axel Wagner <axel.wa...@googlemail.com> >>> wrote: >>> >>>> Sorry, I have to walk that back - my test code was wrong, you are >>>> correct, compilation fails. >>>> The point still stands - they require 1.16, so they set that, not 1.15. >>>> Either way - compilation will fail, why does it matter if it fails because >>>> `embed` doesn't exist before 1.16, or whether it fails because >>>> `//go:embed` >>>> is not supported before 1.16? >>>> >>>> On Tue, Mar 2, 2021 at 1:42 PM Axel Wagner <axel.wa...@googlemail.com> >>>> wrote: >>>> >>>>> There would be no advantage to that - all features are either >>>>> available, or not available, depending on which version you use. There is >>>>> no "go 1.16 without `embed`". It also needs to be set in `go.mod`, >>>>> because >>>>> you might compile modules written for different go versions into one >>>>> binary >>>>> - so which language version to use is part of the module description. >>>>> So, no. Putting a language version into `go.mod` seems to be exactly >>>>> the right way to do this. >>>>> >>>>> On Tue, Mar 2, 2021 at 12:21 PM tapi...@gmail.com <tapi...@gmail.com> >>>>> wrote: >>>>> >>>>>> BTW, I think the embedding functionality introduced in Go 1.16 should >>>>>> not be viewed as a feature. >>>>>> It should be viewed as an API change instead. >>>>>> >>>>> >>>>> I don't understand what you mean by this. There is no intrinsic >>>>> difference between the two. In this particular case, the `embed` package >>>>> adds an API to support a new feature "embedding static files in go >>>>> binaries". >>>>> >>>>> >>>>>> Now Go projects using embedding and setting go directive verison as >>>>>> v1.15 in go.mod fail to compile with Go toolchain 1.16. >>>>>> >>>>> >>>>> They shouldn't do that. If they use `embed`, they require at least go >>>>> 1.16, so they set that. >>>>> I can't reproduce your claim that setting `go 1.15` and using embed >>>>> will fail to compile with a Go 1.16 toolchain. It works fine for me. >>>>> >>>>> IMO, this is unnecessary, for the "//go:embed" directive always >>>>>> requires importing the "embed" package. >>>>>> >>>>>> On Tuesday, March 2, 2021 at 6:14:23 AM UTC-5 tapi...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> Would be better to use compile flags to control each language >>>>>>> features individually? >>>>>>> >>>>>> -- >>>>>> 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/c8e1bd96-78e2-434a-a0cc-4356382e49fcn%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/c8e1bd96-78e2-434a-a0cc-4356382e49fcn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> 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/3bc3bcfc-48d5-47c8-abb0-8fd3197765b8n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/3bc3bcfc-48d5-47c8-abb0-8fd3197765b8n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9acdb3f8-839e-4712-927b-4002fb469c90n%40googlegroups.com.
