Thanks for the answers. I'm not saying that what I proposed in the ticket should be engaged, no! I get the idea why not and I'm okay with that. The related discussion about typification could be addressed on a different thread. The thing I bring here are my doubts about this: I keep wondering if they code that way for any reason. With "code that way" I mean: define a type and then not use it.
Just for clarification - If you see here <https://github.com/golang/go/blob/37f9a8f69d6299783eac8848d87e27eb563500ac/src/net/http/server.go#L2042> you will find a definition for a function. - Then if you look here <https://github.com/golang/go/blob/37f9a8f69d6299783eac8848d87e27eb563500ac/src/net/http/server.go#L2473> you will find that definition again as the type for the second argument. - So, ¿why not employ the type defined in the first place? Don't get me wrong,but if I define a type I tend to use that type where it appears. That is in fact the basis of making types, to use them. So that feeds my questioning! El dom, 27 jun 2021 a las 11:46, 'Axel Wagner' via golang-nuts (< golang-nuts@googlegroups.com>) escribió: > If I understand you correctly, you are suggesting to replace the parameter > type `func(http.ResponseWriter, *http.Request)` with the parameter type > `http.HandlerFunc`. You've been (correctly) told that we can't make that > change, because it would break the Go 1 compatibility change (as there is > code which currently compiles which wouldn't compile after that change). > But you are wondering if, *ignoring* the compatibility guarantee, it would > be a good change. Am I getting this right? > > If so: I don't think it would be a good change. > > First, it's important to realize that the *only* reason, > `http.HandlerFunc` exists at all, is so that you can write a > `func(http.ResponseWriter, *http.Request)` and use it as a `http.Handler`, > in the places where `net/http` expects the latter. You say the type isn't > used - but it is. It's used by *users* of the `net/http` package, to make > their plain functions into `http.Handler`s. It is also used in `net/http` > itself - in the exact function you are referring to > <https://golang.org/src/net/http/server.go?s=77627:77714#L2487>. That is > the exact and only purpose of that type, to make a plain function implement > the `Handler` interface. So, taking a plain function as a parameter *is the > purpose of having the `HandlerFunc` type*. > > You also say that adding types is a good thing. I tend to disagree with > that as a general statement. Adding types is a good thing, if it serves as > important documentation or if it serves to catch bugs. I don't think either > of these would be happening with this change. In terms of documentation - > well, you don't *have* to pass a `http.HandlerFunc`, so there is no reason > for the documentation to make it clear that you should. You can (and > should) just pass a plain `func`. So, using the defined type here wouldn't > serve as documentation, it would document the *wrong* thing. > > As for catching bugs: Making the parameter type a defined type would only > change one thing in terms of type-safety. It would mean that if you define > a *different* type `type MyFunc func(http.ResponseWriter, *http.Request)`, > the compiler would prevent you from writing `http.HandleFunc(…, > MyFunc(f))`. Preventing a bug would thus require that your `MyFunc` type > would have to be used semantically differently from `http.HandlerFunc`. But > that seems *exceedingly* unlikely, given that you defined `MyFunc` in terms > of the `net/http` package. And it would then appear *exceedingly* unlikely, > that you'd accidentally mix the two up - almost all usages of > `http.HandleFunc` will pass the name of some defined function and that will > always work. > > But all of this discussion is really moot. It's a breaking change, so it > can't happen - whether it's a good change or not doesn't exactly matter at > that point. Personally, *if* we could "go back in time" and wouldn't have > to worry about backwards compatibility, my vote would rather be to change > the language to make the HandlerFunc type obsolete > <https://github.com/golang/go/issues/21670> and remove it altogether. > > On Sun, Jun 27, 2021 at 3:53 PM Victor Giordano <vitucho3...@gmail.com> > wrote: > >> Hello gophers! >> >> While studing at this source code >> <https://github.com/golang/go/blob/37f9a8f69d6299783eac8848d87e27eb563500ac/src/net/http/server.go> >> in search for some knowledge and enlightment, i do note that in some file a >> type is defined and then is not used in a place where it could be used. >> This open an interrogant for me, because tipification is often good thing, >> regardless the language I may state, and I express it via a ticket >> <https://github.com/golang/go/issues/46926>. I get the idea that due to >> language grammar changing the code would be a breaking change. >> >> But i keep wondering if they actually do this for a reason.. i mean, >> given the possiblity to get back in time, ¿does the team at golang will >> write the same source code, definiting a type with a name and then >> intenttionally not using it? i mean...i keep wondering if there is any >> reason for defined types and then not use it and using the gitlab channel i >> probably fail to express my initial intention. I do often read some third >> party code, in order to view others minds (or try at least..), what i'm >> asking here is a question in order to get another people point of view. >> >> Thanks again! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/96369719-6200-4765-aee1-83befce04666n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/96369719-6200-4765-aee1-83befce04666n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/VBQrlI6-zW0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHnCTf_4G5ZhGX0EXBKJRN9LcEWbKWOdPiCTKdX6SDqPA%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHnCTf_4G5ZhGX0EXBKJRN9LcEWbKWOdPiCTKdX6SDqPA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- V -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAPUu9sspZS7Vj_oDE%2BbeAz%3DxM0S_mUYRR3EJn4gydHXd9n1Y-g%40mail.gmail.com.
