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.
