HN2new | past | comments | ask | show | jobs | submitlogin

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.



Isn’t function overloading based on the number of arguments a thing in go?

That wouldn’t break compatibility


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...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: