This would technically be a breaking change, because HandlerFunc is a named type. For example, the following line of Go would break with that change:

var f func(pattern string, handler func(ResponseWriter, *Request)) = mux.HandleFunc

The change would be a no-op of HandlerFunc was a type alias, but it can't be, because the point of it is that it has a method.

i don't know where that line is, but i would guess that you may also replace that line; i mean, if you have already "caught" the function signature into a type (HandlerFunc), ¿why don't use that type instead of writing the entire signature again?

I'm not saying that line exists in a particular place; I'm saying it's an example of user code that would break. If the code requires to be changed, usually that's what you call a breaking change.

We can't make this change, so closing this issue.

For questions in general, please see https://golang.org/wiki/Questions.

@mvdan

• I see tipification as a "good" sign.
• I doubt that any client will complaint about using types. (in your example, why you don't use mux.HandleFunc directly)
• I don't see it as a breaking change, i see as an improvement that, perpahs, come late.

@ianlancetaylor why you can't make this change? Forgive if i'm beign a little annoying, I really want to learn the reasons behind something i do believe that is a good sign, i mean, tipification. If the reason of being afraid of clients complaints, it is okay i won't judge (maybe argue) but at least i want to know the motivation behind these things.

@vituchon As @mvdan explained, it would break the Go 1 compatibility guarantee (https://golang.org/doc/go1compat).

so i'm assuming that this works like in Pascal, where an anonymous type (a type without a given identifier) like func(ResponseWriter, *Request) is different from a named type with the same definition. ¿Right?

So perhaps the root of the problem comes from there ... i'm not saying that is good or bad, no .. i'm trying to understand how things work.

For questions about how the language works, please use a forum. See https://golang.org/wiki/Questions. Thanks.

Yes, in Go, a defined type is different than the type with which it is defined. https://golang.org/ref/spec#Type_identity

Got it, thanks for bearing with me.

TD;DR;

I keep wondering if there is any reason to define a type with a name and then not use it the identifier in other parts of the code, specially if you face a similar scenario while building a first version of the source code. I mean, ian and mvdan, don't read me wrong on this, but neither documentation and neither specs about the language tell the idea the people that build the code while i do read your code, in a way, i get to you in order to understand other colegues mind regarding who their handle the abstractions in the current language rules.

I guess i will take this thought to golang nuts channel for further nice discussion.