A lot of people are giving a thumbs down, so I'll try to give a reason behind mine.

This seems like a trivial amount of code and logic for a new piece of API. I understand you wanted more powerful syntax instead, but that being rejected doens't mean that we should fall back to adding multiple "single line" functions to the standard library.

If you personally find such a function useful, I think it's reasonable to add it to your package. After all, it's just five lines :)

My question would be where should this logic live:

• stdlib: community seems to say no
• inline: too complex
• library: if Go gets a guava, boost, or other third party standard library, I think that is endemic of a large problem and community fragmentation.
• module: should I need to reimplement this for every module?

At the end of the day, I do not care about this specific function, but think the core problem is worth tackling.

Requesting inclusion in #33502.

@rsc: bump: ^^

I would ask you to be patient and not ping Russ directly. There are literally hundreds of open proposals, and most are older than yours. They handle however many they can each week.

I attempted to reference the issue, but got no traction for months. I called him out because I did not know what else to do, and he is the primary summary commenter on #33502.

If the core team is drowning in proposals, I do not think the answer is to suggest that we simply need to wait. They are not going to get more bandwidth, and the number of proposals is only going to grow with the language. My frustration is that I feel ignored, and have no mechanism to engage. Can we define a community process to curate, rank, prioritise, and possibly accept proposals without such a bottleneck? I would be understanding if the answer was "not enough people care about this issue", as opposed to "they handle however many they can each week", something with no sense of priority or order.

Also to clarify, I see 200 open proposals, half of which are newer than mine.

Go releases every six months. Even if your proposal got attention, it would take at least six to twelve months to actually have any effect. If waiting for a few months is a dealbreaker, I'm not sure what to tell you :) The processes are just slower for a big language with lots of users and ideas.

For details about the proposal review process, see https://github.com/golang/proposal#proposal-review. It's true that it doesn't specify what criteria is applied when picking issues to start being tracked. Perhaps email golang-dev and ask them to clarify that aspect in the wiki page.

I would be understanding if the answer was "not enough people care about this issue"

To be honest, I think that's why proposals newer than yours have been picked up at this point. I imagine they prioritize proposals which seem more likely to be accepted at first glance.

My concern is that the bottleneck you described, does not need to exist. Many other languages have working groups[0], and do not rely on a resource constrained oligarchy to triage and review proposals. Furthermore, the fact that there is enough opacity to justify comments like "I think that's why" and "I imagine they", is deeply problematic.

0] And sure, the core team can have right of refusal, if they do not want the community to steer the language directly.

I added this to the proposals project. Looks like it was missed.

But, frankly, based on the emoji voting and https://golang.org/doc/faq#x_in_std, I think it's unlikely that this proposal will be accepted.

Your suggestion of ranking proposals is already done to some degree via emoji voting. That said, this is definitely not the right place to discuss the general topic of prioritizing proposals.

Still, I agree that this one got missed. My apologies.

I added this to the proposals project. Looks like it was missed.

That was my fear and why I pinged rsc@. Is there a better way to bump things like this that seem missed? I have a few others that are kind of in the same state, and I want to be respectful of people's time and attention.

But, frankly, based on the emoji voting and https://golang.org/doc/faq#x_in_std, I think it's unlikely that this proposal will be accepted.

My goal is to have the proposal considered and closed, something that does not not necessarily mean accepted or merged.

Your suggestion of ranking proposals is already done to some degree via emoji voting. That said, this is definitely not the right place to discuss the general topic of prioritizing proposals.

Fair, does it make sense to start a go-nuts thread on the topic?

That was my fear and why I pinged rsc@. Is there a better way to bump things like this that seem missed? I have a few others that are kind of in the same state, and I want to be respectful of people's time and attention.

Check whether the issue is in the "Proposals" project (middle of the right hand side of the issue). If not, I guess you can ask me to add it. I'm not sure who has the ability to add issues to projects. I read the issue tracker more than Russ does.

My goal is to have the proposal considered and closed, something that does not not necessarily mean accepted or merged.

Understood, but speaking of being respectful of people's time and attention, if general sentiment is against the proposal, you can also consider retracting the proposal and closing it yourself. @mvdan is right: we are swamped with proposals, and declining a proposal takes time, thought, and mental energy. See also https://groups.google.com/d/msg/golang-nuts/Zqu-HZh3lFg/JYNFqWr_BwAJ .

Fair, does it make sense to start a go-nuts thread on the topic?

Sure, though I don't know how many people will engage. Thanks.

Check whether the issue is in the "Proposals" project (middle of the right hand side of the issue). If not, I guess you can ask me to add it. I'm not sure who has the ability to add issues to projects. I read the issue tracker more than Russ does.

The Proposal label is automatically added by @gopherbot, is it possible to do the same with the project? Is @gopherbot's code open source? I can try and contribute a fix.

Understood, but speaking of being respectful of people's time and attention, if general sentiment is against the proposal, you can also consider retracting the proposal and closing it yourself.

While I agree, I want to think that the visibility of the proposal review process encourages different opinions from those not currently the discussion.

@mvdan is right: we are swamped with proposals, and declining a proposal takes time, thought, and mental energy. See also https://groups.google.com/d/msg/golang-nuts/Zqu-HZh3lFg/JYNFqWr_BwAJ .

This context is really useful, and not totally apparent from comms. I will at least try and start a go-nuts discussion about more community involvement and triage to help shed some of this burden.

Based on the discussion above, this seems like a likely decline.

No change in consensus, so declined.