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 <tapir....@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+unsubscr...@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/CAEkBMfE5-y9HgTq2R9TRjQzsMyMcwg2LgCEr0JbQCkrMR9C-aw%40mail.gmail.com.
