I agree with this idea, and I'm glad that the Go team has come around to this. :) Type aliases end up being very important when you have things like complicate

I agree with this idea, and I'm glad that the Go team has come around to this. :) Type aliases end up being very important when you have things like complicated closure types and generics. They are also useful for migration, as the article notes. It's also nice for packages to be able to reexport names from other packages: perhaps your library depends on some internal packages that you only want to expose a few types from. One word of advice for Go developers if this is implemented: Pay attention to getting error messages in the compiler right. Ideally you want to refer to types by the name the programmer was using at the place the error occurred, not the underlying internal name. This requires hanging on to typedef information through more internal stages of the compiler than just name resolution. Clang does a great job of this with its "a.k.a." functionality.