Type aliases

suggest change

Type aliases were introduced in Go 1.9 to make code refactoring easier.

Imagine you have a package foo that exports type Bar.

You want to rename type Bar to NewBar.

Without type aliases you would have to change all the packages that use foo.Bar to use foo.NewBar at the same time you’re renaming the type.

With type aliases you can split this into a 2 step process.

First update dependencies by introducing an alias for foo.Bar and replacing all uses of foo.Bar with the alias.

import "foo"
type Bar = foo.Bar // Bar is now an alias of foo.Bar

Now you can rename foo.Bar to foo.NewBar and update the alias:

import "foo"
type Bar = foo.NewBar

This is a much smaller change.

You can now gradually get rid of the alias and use the new foo.NewBar type directly.

The process sounds like a hassle, but in large code bases it can be a better approach than renaming everything at once.

It’s tempting to use type aliases for other things, but you should resist.

Type aliases add a layer of indirection, which hurts readability of the code. There should be a good reason to use them.

To learn more, you can read the spec.

Feedback about page:

Feedback:
Optional: your email if you want me to get back to you:



Table Of Contents