Hello! My unconfirmed, but perhaps mistaken understanding of the `go` directive in a go.mod file was that it covered both the language and the stdlib. Since the stdlib docs indicate the version a given symbol was introduced, and since build processes validate that signature breakages do not occur, it seemed plausible that go.mod would also perform this validation as well, but it seems this is not the case:
https://go.dev/play/p/HmEahfVxXTb?v=goprev fails when run with Go 1.20, yet succeeds when run with Go 1.21. I'd have expected this to also fail in Go 1.21 due to the go.mod file listing 1.20, in the same way as I'd expect Go 1.21 to reject use of the `clear` builtin when go.mod does not specify at least 1.21. This can be a bit surprising when managing a library, for example, since the message we get for wrong-version use of language-level features is much clearer than what we see for misversioned use of stdlib functionality. It's also surprising, because this does mean that dependencies on 3rd partly modules have enforcement and error reporting which is more crisp and thorough than dependencies on the stdlib itself. Is there any documentation/rationale about this contract covering the language, but not the stdlib? Thanks! Kevin Gillette -- 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/813b922c-5d71-4829-a6a5-30b68ffdf164n%40googlegroups.com.
