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/CAEkBMfGn50YTgTNa4GeQd%3DYkRRfHbfUwXmCFfDUwWy9UEm9uPw%40mail.gmail.com.
