Isn’t that just a consequence of Go’s backwards compatibility guarantee?

Adding new arguments to the Mux interface would break existing code, given the method signature can’t be changed, these magic strings seem like a reasonable compromise. It not like HTTP verbs are going to change anytime soon, and it’s trivial to validate them during register, or via static analysis. So I’m not sure what value the use of constants would bring, especially if it either broke backwards compatibility, or forced the creation of a new, but slightly different mux API that would have to live in parallel with the old API forever.

Go does not have function overloading

ah, alright, thanks! I didn't know.

Surely the changes to panic on conflicting routes being discussed upstream already prove they're willing to flex on that guarantee?

That’s not a breaking change.

How is "this api usage was allowed before and now panics" not a breaking change?

Which specific API usage was allowed before and now panics? As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice, which in my books is just a bug.

Certainly it's technically a breaking change, but there's huge difference between making all existing usage of the mux interface incompatible with the new changes, and only making obviously incorrect and buggy usages of the interface incompatible.

> As far as I can see the only historically allowable API usage that would now panic, is registering exactly the same path twice.

This has always resulted in a panic[0].

[0]: https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/ne...

But isn't it a magic string already, because of the {parameter} parsing?

I don't really see an issue in treating it as if it was just `Request-URI` (in RFC2616 terms) with some parameter magic, and became a Request-Line-resembling `[ Method SP ] Request-URI`, which is fully backwards-compatible and isn't exactly surprising to anyone. I think it's pretty much obvious what it does even if one never sees the documentation.

And given that `Method` is either one of a few predefined constants or `extension-method = token`, and `token` excludes whitespace, slashes and all sort of brackets I don't think there's a chance of confusion or misparsing there, even for weirdest custom methods.

> And given that `Method` is either one of a few predefined constants

The compiler via a method call or parameter can capture this constraint in a pretty straight forward way. I'm not sure why an API would give that up

While I do agree it’s kind of strange, the reasoning is pretty clear. The desire to not break or change the existing public interface.

Just add a new method with a new name. Vastly better than the proposal at hand.

Is it vastly better, though?

With this proposal if you already have an app using mux, you can change one line and you have app using new mux which you can then evolve to take advantage of additional capabilities.

With new name you have to rename all your codebase.

Not to mention that writing a wrapper with an API to your liking is few trivial lines of code so this is bike shedding at its finest.

I shouldn't have to wrap a poor design choice.

That was my gut feeling as well, but honestly when using Gin, having methods like .Get(), .Post() etc. has never solved anything for me. Having a single registration method with the method in the string is probably 100% fine.

"probably" is key Here. this introduces the possibility of typo erros that can even be discovered late. Now you will need a Vet check to make sure that GET, POST etc are written correctly instead of letting the compiler to do it's job. .Get(), Post() get compiler guarantees that they are sending the right Method string.

I agree on principle, but in practice routers rely on arbitrary strings anyway. I don't see why the verb is not just a part of the route.

In my head it's as if we did this:

    http.Segments("foo", "bar", http.Param("barID"), "baz")

instead of:

    /foo/bar/:barID/baz

Is it sliiiightly safer? Yes. Is it insane? Also yes.

What's wrong with automatically registering a HEAD route?

"The HTTP HEAD method requests the headers that would be returned if the HEAD request's URL was instead requested with the HTTP GET method. ". So it goes against the HTTP spec.

In practice much bigger practical problem is that no-one handles HEAD.

I sure don't.

And those that do probably aren't careful about HTTP headers either.

So in practice this an improvement for most.

And if you don't like how it works, there are plenty of alternatives to use.

How does it go against the HTTP Spec. The HEAD method could be autoregistered for all handlers of GET Requests and library makes sure no body is sent (Basically it's a autoregistered middleware that wraps the get handler and overwrites the reponse writer with an empty body.)

Arguably this is more correct that letting the users declare a separate Handler that can neither guarantee the same headers as the the GET Handler not guarantee that the body is not sent the response.

Go implicitly buffers the first 512 bytes to sniff a content-type header so it's no like the status quo is free of arguably incorrect magic.