Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: establish RFP/RFC process for language feature proposals #29860
Go 2 Language Change proposals for new features are accumulating steadily, and consuming time on the part of the Go team and proposal proponents. (Meanwhile, there has been relatively little published response to the feedback and counter-proposals regarding the Go 2 Draft Designs for Error Handling and Generic Programming.)
Those of us interested in proposing or discussing new language features would benefit from guidance by the Go team regarding which sorts of features have priority, and which are off the table, having been considered and discarded. And detailed guidance about priority features could leverage the whole community for development of comprehensive proposals.
Therefore I'd like to suggest creation of a process that defines Language Feature Requests for Proposal & Requests for Comment, aka FRFPs & FRFCs. The Go team would issue FRFPs (describing problems of current practice, experience reports, and functional requirements) to solicit design concepts from the community. The Go team and community members would publish FRFCs (describing semantics, syntax, and use cases) to present design concepts for discussion and development.
Rust, for example, has an extensive RFC process. In contrast, the current Go proposal process and template make hardly any demands on proposal authors, forcing readers to engage in discussion just to understand a proposed concept.
EDIT: Inviting the community to submit FRFCs to fix widely-discussed problems is a community building exercise, especially where the result is adoption of a concept originating outside the Google team.
Documentation of the FRFP/C process would cover:
Briefly, I'd imagine the following: Both types of document should be discussed via golang-dev, and discussion should begin before publication. FRFPs should be covered on the Go blog when published. Both types should be linked from wiki pages curated by the Go team, and committed to the Go proposal repo. If an FRFC reaches the draft implementation stage, an issue should be filed on the github issue tracker.
An FRFC that addresses an FRFP could be fairly short; the first draft might be a collection of commented code samples. An FRFC that doesn't address any FRFP would have to provide key elements of an FRFP, e.g. real-world examples of how existing practice falls short, and an outline of potential requirements for any reasonable solution (including points that the author chose not to address in their design concept). FRFCs of this type might prompt the Go team to draft an FRFP in response.
I'd also suggest that this process be applied to the Error Handling and Generic Programming features, which would mean reorganizing the Draft Design documents into FRFP & FRFC docs, and adding to each as necessary to meet the specifications of the newly-defined process.
This process could apply to other areas central to the Go ecosystem, e.g. tooling. It would probably not apply to minor language adjustments (e.g. #19113 & #19308) or stdlib proposals, which are by definition more modest in scope and impact than new language features.
I respectfully disagree. I feel the process you propose would be too heavy weight. I think it's perfectly fine to propose a feature without having to design all details of it. Especially because it always needs to be discussed whether or not many people are interested in the feature or not.
The current proposal process is fine, but the document at https://github.com/golang/proposal/blob/master/README.md is outdated, because it still mentions that language changes are unlikely to be accepted. Rather, there are new criteria for this in: https://blog.golang.org/go2-here-we-come which should be integrated into the former document.
Secondly, the latter blog post mentions that there will be a Go2 task force. It would be nice to hear who they are and to see that they are getting active. One document which they could produce is a list of language features that were rejected and thus not likely to be added plus rationale, and a list of features that are under discussion and that may become part go Go in the future, with the status of these issues and the problems that are still blocking the feature.
Anybody can see Go 2 language proposals that were rejected at https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed+label%3Ago2+label%3Alanguagechange+ . (There are currently 168 such proposals). Each issue has a comment or discussion about why it was rejected.
Thanks for the suggestion, but I don't really see how this would make things better. While the current language proposal process is hardly perfect, I don't think the problems are due to a lack of formal processes.
Go is a language that has always developed based on practical use. Ideally language change proposals should flow from people who know the language well and are actively using it. Where they find areas where they are unable to express important concepts, or find them awkward to express, they can look for ways to improve their experience. So having the core Go team issue "feature requests for proposals" doesn't feel right. Those should ideally flow organically from people using the language.
Or to put it another way, if we did issue feature requests for proposals, I think we would simply point out the same areas where many people are proposing changes anyhow, such as some form of readonly or immutable values, or error handling (for which there is already a design draft). We would point out those areas because many experienced Go programmers encounter problems in those areas and some of them are moved to make language change proposals. There are no esoteric areas where Go needs improvement, or, rather, I'm sure there are, but we wouldn't ask for improvements in those areas anyhow because they don't really come up in practice.
@ianlancetaylor , thanks for the tip. I guess I can use a similar https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Ago2+label%3Alanguagechange+ to see the open issues . Also, rereading the document I realize that you, in essence, are the "Go 2 task force", right? From the list of closed issues I can see you have been very active in this lately, so I'd like to thank you for your efforts. So I apologize if I came off impatiently in my previous message.
However, I still think that the README.md should be updated to reference the blog post for clarity.
I'm not really the "Go 2 task force." I don't think we really have a "task force," although that sounds energetic; I would say that we have a "committee." I'm just the person who takes notes for the committee. Actually, it's more like I take notes for the preliminary committee which filters out the issues that are obvious non-starters and classifies other issues for a deeper look by more people. The preliminary committee is me, @griesemer and @bradfitz.
You didn't seem impatient, no need for an apology.
I agree about the README, I'll do something now.
pushed a commit
Jan 22, 2019
The value of Feature RFPs is not merely to "point out" a problem, it's to describe and publicize requirements for an acceptable solution, and thereby solicit comprehensive, workable Feature RFCs.
IMHO, the FRFP approach would be more effective for the Error Handling issue than the tack taken to date. The Draft Design for Error Handling contains essentially zero functional requirements, and no mention of possible extensions to its novel concept. You're probably familiar with my menu of possible requirements for Go 2 error handling; that is what an FRFP would contain. (I'm not familiar enough with the Draft Design for Generics to comment on it.)
Also, inviting the community to submit FRFC documents to fix a widely-discussed problem is a community building exercise. If the process resulted in the adoption of a concept originating outside the Google team, it would demonstrate that in the Go open source community, the best ideas win.
As I wrote in the text, "An FRFC that addresses an FRFP could be fairly short; the first draft might be a collection of commented code samples."
Asking the author of a standalone FRFC to describe the requirements driving their design is a blessing, not a burden; understanding & documenting requirements both clarifies the design concept and yields a more productive discussion.
The current proposal process encourages people to throw barely-cooked spaghetti at a wall; not a good use of anyone's time. It would be more illuminating to see simple bug reports like, "Clients misuse this third-party API due to lack of immutable/read-only arguments," which detail a specific problem.
@ianlancetaylor Thanks for your efforts, and those of everyone on the "commitee". Though I suggest you rename yourselves the "Go 2 Preparation Task Force", because, as you say, that sounds more energetic. :) Good to see the README will be updated.
@networkimprov I don't see any problem with people just throwing an "barely-cooked spagetti" idea "at the wall", or, more likely, here in the issue tracker, because that encourages everyone to participate. It also makes it clear which new language features many people are interested in, as per Go2 ciriterium 1. That is the first step, identify a need for the feature.
Of course, once an issue turns out to be in high demand, then there will be a long discussion to work out the details. For that, I agree that it might be a good idea to have everyone who wants to flesh out the proposal to write a Go Language Feature Design Document, in stead of just making a few comments here and hoping someone else will do the hard work of actually designing the feature.
The current counter proposals, for, say, the error handling feature are often quick blog posts or short comments so they can't easily be compared with each other. Having a common GLFDD would help with that considerably, and also help to weed down the possible implementations for a feature.
I'm having a hard time distinguishing this suggestion from the current proposal process.
It sounds like what you are describing is basically step 3 at https://go.googlesource.com/proposal#the-proposal-process, namely writing a design doc.
One reason we don't jump right to step 3 is precisely to reduce work for authors in the common cases where (1) the proposal is definitely fine without a worked doc or (2) the proposal is definitely not going to be accepted, or has been discussed before, or has some fatal flaw in its current form that would be easier to adjust in a brief discussion before writing a long doc. That seems like a real benefit.
What, concretely, would you change about the current proposal process, and how would you make sure not to give up the benefit mentioned in the previous paragraph?
For what it's worth, we called those draft designs precisely because they are not yet firm enough to be considered real proposals. They're sketches of what we're thinking, to provoke discussion, not to provoke a formal process. They also happen to be elaborate because they tend to touch a lot of issues, but we don't expect that to be true of all proposals, or even most. You can get a sense of the variety of proposal complexity by skimming through the "Proposal-Accepted" label on this issue tracker.
I am not at all suggesting that new feature proposals should begin with a Design Document.
Above I called for
I then suggested the "Language Feature Request for Proposal (FRFP)", which is issued by the Go team, and answered by any number of "Language Feature Requests for Comment (FRFC)", which anyone may submit.
An FRFP a) describes a problem of current practice, b) summarizes relevant experience reports, and c) identifies functional requirements. It's similar to a Design Document, but it does not propose a design. Only the Go team publishes FRFPs.
An FRFC offers a design, giving a) semantics & syntax, and b) use cases. An FRFC first draft could be brief, e.g. "a collection of commented code samples". If it leaves unaddressed any requirements in the relevant FRFP, it should explain why. It does not describe a problem (unless it's a standalone FRFC, see below). Anyone may publish FRFCs.
The numerous counter-proposals sparked by the Go 2 Draft Designs demonstrate that many in the Go community immediately interpreted the Draft Designs as FRFPs.
In my response to @ianlancetaylor I wrote, "the FRFP approach would be more effective for the [Go 2] Error Handling issue than the tack taken to date. The Draft Design for Error Handling contains essentially zero functional requirements, and no mention of possible extensions to its novel concept. You're probably familiar with my menu of possible requirements for Go 2 error handling; that is what the FRFP would contain." The proposed syntax & semantics would appear in a separate FRFC.
There is also a need for a standalone FRFC (that doesn't address any FRFP), which would include "an outline of potential requirements for any reasonable solution". Its first draft could be brief; a code sample following each requirement listed. This is similar to a Design Document, but can begin as a short email.
The process I suggest would "not apply to minor language adjustments ... or stdlib proposals, which are by definition more modest in scope and impact than new language features."
P.S. I tried hard to make all this clear in the issue text and my one follow-up comment. Any input on improving the text would be welcome.