sorry, the 4th setup reports "//go:embed only allowed in Go files that import "embed"".
On Tuesday, March 2, 2021 at 8:38:05 AM UTC-5 tapi...@gmail.com wrote: > > 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/a200ce21-0f52-4b9a-9764-89a6201fe3b3n%40googlegroups.com.
