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.wagner...@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.wagner...@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 <tapir....@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+unsubscr...@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/CAEkBMfFR3JLa295acGSEVfb9eiMnJGUT-2xnLzvpp9vJ7MLUYQ%40mail.gmail.com.
