Following https://golang.org/doc/faq#x_in_std, why does this really need to be in the standard library?

It's true that complex HTTP servers likely need a fancier router, but they probably also need other fancy things that don't need to be in net/http. As long as net/http is composable and can be extended via third party packages (which it is), I think the current status is fine.

You could argue that net/http should include a slightly more powerful router, but I don't think we would all agree on what exactly that would look like. For example, I use https://godoc.org/github.com/go-chi/chi pretty regularly, but its design greatly differs from other third party routers. Its API surface is also far larger than something we could fit into net/http, too.

So, if you're serious about this proposal, I think you should really specify what changes to the API you're suggesting.

@mvdan your point of "unable to specify how the standard library router should look like when we say more powerful" is vague. Does it mean, we can not standardize how the standard library should look like?

If it is, then how did the Go team standardized the template (html or text) syntax when there are multiple other ways of doing the exact thing (like pug, handlebars etc)?

This is just an example. Not able to standardize a new feature is a huge mental restriction. The way the template language syntax was standardized and placed in the library is very much same for any case of making/adding something to the standard library.

Following https://golang.org/doc/faq#x_in_std, why does this really need to be in the standard library?
I have stated the reason explicitly in my proposal. Take a look at it

Does it mean, we can not standardize how the standard library should look like?

Yes, it's possible. The first step is for you to propose how such an API would look like in detail.

Yes, it's possible. The first step is for you to propose how such an API would look like in detail.

Why it should be me to propose that API? It's already there in countless 3rd party libraries. Take a look at them and you should have a firm believe that "how the API will look like". This is such a basic feature. And when you advertise "the language for cloud native apps" but has lacking in simple as the net/http router, it sounds really silly.

If you guys still unsure about how it should look like, then I'm signing off. It's awful to talk about this when you know what I mean but acting like you don't understand it.

It's already there in countless 3rd party libraries.

I'm not clear on exactly what you're proposing. Are you saying we should include the API from multiple third party libraries at once? Or that we should look at many of them, and come up with some sort of unified API on our own?

A proposal should propose a very specific and detailed change to Go. It seems to me like "add a regex-based router to the standard library" is too generic for any work to be considered or done. Hence why I'm asking that you propose a specific change that can be evaluated.

Ok, here's the proposal in different way:

"Can we implement basic features on the standard net/http router like gorilla/mux one? So that we don't have to rely on 3rd party libraries for such basic things like router"

Does it still sound generic?

Does it still sound generic?

Yes.

Yes

Instead of putting "Yes", explain why

Look at it this way. The core Go team is a relatively small number of people who has to deal with hundreds of proposals and thousands of issues. What you are suggesting is at this point very vague.

If your suggestion is: make net/http router work exactly like the gorilla/mux router, then our first response is going to be the FAQ cited above: https://golang.org/doc/faq#x_in_std. This isn't a casual or superficial objection: the gorilla/mux package already exists. You can already use it. There has to be a reason to bring it into the standard library. What is that reason?

Perhaps the discrepancy is that you started off by saying "Most of the time, I try to use the standard library as much as possible." Our stance is as cited in the FAQ: "Most new code should live outside of the standard library and be accessible via the go tool's go get command."

There is definitely a tension between "put everything useful in the standard library" and "encourage a thriving ecosystem of third party packages." We have to find the right balance between those choices.

For this proposal, you'll need to explain why the balance is in power of putting more into the standard library. And to make that argument you'll need to show exactly how the standard library should change: what new functions it should have, and how they should behave.

But start by saying why the balance here tips toward moving more functionality into the standard library. The only clear reason I see here is "We want the standard library to be more robust." Let me counter that by claiming that adding more features, especially to a complex package like net/http, makes it larger, harder to test, harder to understand, and, in my opinion, actually less robust.

Thanks.

I believe this proposal is now a duplicate of #61410.

This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group