From e8781e0e14d87e723c14299ce8461cdb08a3b9e2 Mon Sep 17 00:00:00 2001 From: Ian Lance Taylor Date: Tue, 16 Jun 2020 10:21:41 -0700 Subject: [PATCH] [x/blog] content: add generics-next-step article For golang/go#15292 Change-Id: Iafefd3dd016a0d78907af408903f0186df42dd3b Reviewed-on: https://go-review.googlesource.com/c/blog/+/238241 Reviewed-by: Robert Griesemer X-Blog-Commit: 1d9389492a1d541f71729b5f1c1b9c5c4f045171 --- blog/content/generics-next-step.article | 139 ++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 blog/content/generics-next-step.article diff --git a/blog/content/generics-next-step.article b/blog/content/generics-next-step.article new file mode 100644 index 0000000000..5523f0a98e --- /dev/null +++ b/blog/content/generics-next-step.article @@ -0,0 +1,139 @@ +# The Next Step for Generics +16 Jun 2020 +Tags: go2, proposals, generics +Summary: An updated generics design draft, and a translation tool for experimentation + +Ian Lance Taylor +Robert Griesemer + +It’s been almost a year since we [last wrote about the possibility of +adding generics to Go](https://blog.golang.org/why-generics). +It’s time for an update. + +## Updated design + +We’ve been continuing to refine the [generics design +draft](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md). +We’ve written a type checker for it: a program that can parse Go code +that uses generics as described in the design draft and report any +type errors. +We’ve written example code. +And we’ve collected feedback from many, many people—thanks for +providing it! + +Based on what we’ve learned, we’re releasing an [updated design +draft](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md). +The biggest change is that we are dropping the idea of contracts. +The difference between contracts and interface types was confusing, so +we’re eliminating that difference. +Type parameters are now constrained by interface types. +Interface types are now permitted to include type lists, though only +when used as constraints; in the previous design draft type lists were +a feature of contracts. +More complex cases will use a parameterized interface type. + +We hope that people will find this design draft simpler and easier to +understand. + +## Experimentation tool + +To help decide how to further refine the design draft, we are +releasing a translation tool. +This is a tool that permits people to type check and run code written +using the version of generics described in the design draft. +It works by translating generic code into ordinary Go code. +This translation process imposes some limitations, but we hope that it +will be good enough for people to get a feel for what generic Go code +might look like. +The real implementation of generics, if they are accepted into the +language, will work differently. +(We have only just begun to sketch out what a direct compiler +implementation would look like.) + +The tool is available on a variant of the Go playground at +[https://go2goplay.golang.org](https://go2goplay.golang.org). +This playground works just like the usual Go playground, but it +supports generic code. + +You can also build and use the tool yourself. +It is available in a branch of the master Go repo. +Follow the [instructions on installing Go from +source](https://golang.org/doc/install/source). +Where those instructions direct you to check out the latest release +tag, instead run `git checkout dev.go2go`. +Then build the Go toolchain as directed. + +The translation tool is documented in +[README.go2go](https://go.googlesource.com/go/+/refs/heads/dev.go2go/README.go2go.md). + +## Next steps + +We hope that the tool will give the Go community a chance to +experiment with generics. +There are two main things that we hope to learn. + +First, does generic code make sense? +Does it feel like Go? +What surprises do people encounter? +Are the error messages useful? + +Second, we know that many people have said that Go needs generics, but +we don’t necessarily know exactly what that means. +Does this draft design address the problem in a useful way? +If there is a problem that makes you think “I could solve this if Go +had generics,” can you solve the problem when using this tool? + +We will use the feedback we gather from the Go community to decide how +to move forward. +If the draft design is well received and doesn’t need significant +changes, the next step would be a [formal language change +proposal](https://golang.org/s/proposal). +To set expectations, if everybody is completely happy with the design +draft and it does not require any further adjustments, the earliest +that generics could be added to Go would be the Go 1.17 release, +scheduled for August 2021. +In reality, of course, there may be unforeseen problems, so this is an +optimistic timeline; we can’t make any definite prediction. + +## Feedback + +The best way to provide feedback for the language changes will be on +the mailing list `golang-nuts@googlegroups.com`. +Mailing lists are imperfect, but they seem like our best option for +initial discussion. +When writing about the design draft, please put `[generics]` at the +start of the Subject line and to start different threads for different +specific topics. + +If you find bugs in the generics type checker or the translation tool, +they should be filed in the standard Go issue tracker at +https://golang.org/issue. +Please start the issue title with `cmd/go2go:`. +Note that the issue tracker is not the best place to discuss changes +to the language, because it does not provide threading and it is not +well suited to lengthy conversations. + +We look forward to your feedback. + +## Acknowledgements + +We’re not finished, but we’ve come a long way. +We would not be here without a lot of help. + +We’d like to thank Philip Wadler and his collaborators for thinking +formally about generics in Go and helping us clarify the theoretical +aspects of the design. +Their paper [Featherweight Go](https://arxiv.org/abs/2005.11710) +analyzes generics in a restricted version of Go, and they have +developed a prototype [on GitHub](https://github.com/rhu1/fgg). + +We would also like to thank [the +people](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements) +who provided detailed feedback on an earlier version of the design +draft. + +And last but definitely not least, we’d like to thank many people on +the Go team, many contributors to the Go issue tracker, and everybody +else who shared ideas and feedback on earlier design drafts. +We read all of it, and we’re grateful. We wouldn’t be here without +you.