The main takeaway here is that the dev.typeparams branch has been merged
into the Go master branch. Since we will definitely get generics in Go
1.18, IMO it's time to start thinking about how to eliminate tech debt in
ATC using type parameters.
If you want to test it out, here is a small generics example. Using `go`
build from the golang.org/x/go master branch, compile with `go build
-gcflags -G=3`. Your `go.mod` needs to specify `go 1.18`:
```
package main
import "fmt"
func myPrint[MyType any](messages ...MyType) {
fmt.Print(messages, "\n")
}
func main() {
myPrint[string]("Hello", "generic", "world!")
}
```
Expected output:
[Hello generic world!]
-Zach
---------- Forwarded message ---------
From: Carlos Amedee <[email protected]>
Date: Fri, Aug 13, 2021 at 1:29 PM
Subject: [golang-dev] Tree is open for general Go 1.18 development
To: golang-dev <[email protected]>
Hi gophers!
The early CLs have all landed (see issue 47351
<https://golang.org/issue/47351>), and the tree is now open for general
development for the Go 1.18 release.
The doc/go1.18.html draft file will be made available soon (it's CL 342070
<https://golang.org/cl/342070>), so you can start documenting your changes
while they're fresh in memory (less work to do at the end of the release!).
We will remove all "wait-release" tags on Gerrit CLs (to be replaced with
"ex-wait-release"), as well as ping issues in the Go 1.18 milestone that
are marked as "early-in-cycle".
I'll copy these points from our past tree reopenings, since they're helpful
to keep in mind:
-
Check build.golang.org Before Submitting
Before starting to submit your CL or a stack of CLs, please check that
the tip is green at https://build.golang.org. If there is a widespread
test failure, please wait, or better, help with efforts to diagnose and fix
the failure.
-
Revert Sooner
When a change that landed on master results in a confirmed failure or
unintended behavior change, we ask everyone to revert that change sooner,
instead of letting it stay merged. For example, if we learn that a change
in unspecified behavior of a function like url.Parse causes breakage, then
it is better to roll back while thinking about how to address the issue.
This helps ensure master is more stable, making it easier for people who
are developing other changes.
As always, please proceed cautiously, and happy Go 1.18 development!
Carlos
--
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-dev/0a56b664-a2ec-47cf-9e9c-d4ad609f3a8bn%40googlegroups.com
<https://groups.google.com/d/msgid/golang-dev/0a56b664-a2ec-47cf-9e9c-d4ad609f3a8bn%40googlegroups.com?utm_medium=email&utm_source=footer>
.