Expectations for generics in Go 1.18
groups.google.com
Expectations for generics in Go 1.18
1–10 of 209 posts
Re: Expectations for generics in Go 1.18
#2Very reasonable caveats for a feature as big as generics.
Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
Re: Expectations for generics in Go 1.18
#3> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts.
I have a feeling this won't happen.
Re: Expectations for generics in Go 1.18
#4Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics?
The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something that looked like a function.
Re: Expectations for generics in Go 1.18
#5Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
I don't see how it changes error handling. To implement a generic error handling function you would need a non-local return statement (panicing is not error handling). And a generic monadic Result type would make error handling more verbose due to its reliance on closures for subsequent actions.
Re: Expectations for generics in Go 1.18
#6Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0].
Re: Expectations for generics in Go 1.18
#7Related discussion from 10 days ago:
go: don't change the libraries in 1.18
Re: Expectations for generics in Go 1.18
#8Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502
> Does anyone know the impetus for using [] in generics?
Yes: https://go.googlesource.com/proposal/+/refs/heads/master/des...
Re: Expectations for generics in Go 1.18
#9How are they implemented?
Compile time? With template expansion like D and C++?
Re: Expectations for generics in Go 1.18
#10> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts. I have a feeling this won't happen.
You're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18.
My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, which is difficult, because I really like the feature.