Thanks to all for the answer, i really try to see any actual reason but i still don't get it. For me, to my humble acknowledgement, if I define a type I tend to use everywhere it appears. Period. End of the story.
> FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` because there exists a defined type with the same underlying type as the parameter is a bit like arguing every function that takes an `int64` should instead take a time.Duration <https://golang.org/pkg/time/#Duration>. Allow me to put in different words: if you define `func doSomething(duration int64)` at least i will argue why don't employ time.Duration <https://golang.org/pkg/time/#Duration> as a type there, if the parameter actually represents a Duration that is also a defined type, ¿you don't?. I won't say the same about other things that hold an int64 that represents for example an ID of record in a database. El dom, 27 jun 2021 a las 12:56, 'Axel Wagner' via golang-nuts (< golang-nuts@googlegroups.com>) escribió: > FWIW, arguing that `http.HandleFunc` should take a `http.HandlerFunc` > because there exists a defined type with the same underlying type as the > parameter is a bit like arguing every function that takes an `int64` should > instead take a time.Duration <https://golang.org/pkg/time/#Duration>. > That's just not how types tend to work. > > It makes no sense for `http.HandleFunc` to take a `http.HandlerFunc`, > because it's purpose is specifically to work on a plain function. If you > have an `http.HandlerFunc`, you can already just call `http.Handle` - there > is no need to make a separate function that takes a *specific* > implementation of `http.Handler`. > > On Sun, Jun 27, 2021 at 5:51 PM Axel Wagner <axel.wagner...@googlemail.com> > wrote: > >> On Sun, Jun 27, 2021 at 5:25 PM Victor Giordano <vitucho3...@gmail.com> >> wrote: >> >>> 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. >>> >> >> As I said: It's used plenty of times. Both inside of `net/http` and >> outside of it. >> >>> >>> - So, ¿why not employ the type defined in the first place? >>> >>> I feel like I gave a bunch of reasons for this too. >> >> >>> 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 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/CAEkBMfHiQP0WEbGPrFkY5gSzaaiQ5OqisySiy8_yUdfVAE-v6w%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHiQP0WEbGPrFkY5gSzaaiQ5OqisySiy8_yUdfVAE-v6w%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/CAPUu9svv9phXbMSztSpS%3DU0L7aVF5zn3Oz9Qs_Bmk%2BOFneO-Lg%40mail.gmail.com.
