Re: [go-nuts] go.mod go directive coverage of stdlib contract?
Thanks! This is a pitfall that doesn't come up often, but would arise when "polyfilling" later behavior into an earlier version, in conjunction with version build tags. It's something I'll need to keep in mind in the future. -- Kevin On Saturday, November 4, 2023 at 7:19:29 PM UTC-6 Kurtis Rader wrote: > On Sat, Nov 4, 2023 at 5:05 PM 'Kevin Gillette' via golang-nuts < > golan...@googlegroups.com> wrote: > >> 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. >> > > Yes, you are mistaken :-) See https://go.dev/doc/modules/gomod-ref#go. It > affects the language features available. It does not affect the stdlib > features. If you say your program requires a minimum version of 1.20 you > are also stating that it will work with the stdlib provided by Go 1.20. > Also, note that it is the minimum Go version required by your code. Not the > maximum. > > >> 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. >> > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- 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/9dd2f00e-c4d3-415a-a131-f8224a165a00n%40googlegroups.com.
[go-nuts] go.mod go directive coverage of stdlib contract?
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.
[go-nuts] Clarification on the Compatibility Promise regarding Version Build Constraints
Hello! https://github.com/golang/go/issues/63662 was submitted as a bug report, but did not offer much explanation in its response, and it's still not clear how this is not a compatibility breakage. > Build tags are explicitly designed to allow skew away from the main version declared in go.mod. I haven't been able to find any documentation of this explicit design intent, but perhaps I've looked in the wrong places: - https://pkg.go.dev/cmd/go#hdr-Build_constraints mentions that version tags exist, but does not go into much more detail than that. - In https://go.dev/ref/mod#go-mod-file-go, neither the "go directive" nor "toolchain directive" sections mention how they relate to tags. Neither of the above describe the interaction/selection mechanism between go.mod *go directive* values and version build tags. Furthermore, https://go.dev/doc/go1compat does not mention build tags as a potential exception to the compatibility promise. If there was a explicit design decision to have version build tags skew from the *go directive* version (in a way that could cause code to start failing to compile after merely upgrading the toolchain), and if it's already not documented somewhere I failed to find, then it would be a caveat to the compatibility promise that is probably worth explicitly spelling out. Thank you! 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/a4ffa17c-5f4f-45b0-a75c-90fe546e3e93n%40googlegroups.com.
Re: [go-nuts] Re: Generics and parentheses
On Wednesday, July 15, 2020 at 6:41:51 AM UTC-6 Michal Strba wrote:
> What about using a dot when specializing in bodies?
>
> func main() {
> x := zero.() // requires a dot
> }
>
What are all the kinds of "generic expressions" we would need to support?
Go allows incomplete floating point literals (such as `x := 3.`)... Could
angle brackets ever appear on the right side of such a floating point
literal to mean something generic? If so, it would be ambiguous with a
less-than comparison.
--
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/c94e7926-47c8-4530-9b37-70066a1be72dn%40googlegroups.com.
