3 ms·

It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/pat

It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/path") Rather than the current: ("GET /path") Odd.

badrequest 3y ago
It adheres to the Go 1 compatibility promise.
ilyt 3y ago
It's mistake they can't fix without breaking existing code or introducing new function. But I'd prefer just a bunch of mux.GET/mux.POST/etc functions instead of that.
- gavinray 3y ago
  Oh damn, no overloading in Go, yeah that rules out the above I suppose. Agreed on the dedicated GET/POST etc functions though.
- drdaeman 3y ago
  You’ll need new HandleMethod(method, uri, …) anyway, because otherwise you won’t be able to support any less common or non-standard methods.
EspressoGPT 3y ago
This is a case where I, as a Go developer, would prefer to have function overloading for the sake of backwards compatibility . Because the compatibility promise is great, but the quirks caused by it aren't.