A string in Go is a value. Thus, a string cannot be
However, a pointer to a string (or
*string) can be
A good rule of thumb is to use normal strings unless you need
nil. Normal strings are easier and safer to use in Go. Pointers require you to write more code because you need to check that a
*string has a value before dereferencing.
An empty string value
nil are not the same thing. When programming, if you can’t think of reason you would need
nil, then you probably don’t need it or want it.
So when should I use a pointer to a string?
There may be times when you should use
*string. For instance, you should probably use a
*string for struct properties when deserializing json or yaml (or anything) into a structure.
Consider code where a json document is deserialized into a struct consisting of normal string properties.
You’ll notice that both
HostName are stored as empty strings. This is correct behavior for
Version, but should
HostName really be an empty string?
The answer to that question depends on your program. If it is acceptable for a missing property to be unmarshalled into an empty string, then there is no problem. In other words, if you will handle missing json properties and empty json properties the same, then use a normal string.
But what if
"" is a valid configuration value for
HostName, but a missing property is not valid?
Answer: use a
Notice that with
*string, you can now differentiate between a missing property or
null value from an empty string value in the json document.
tl;dr; Only use a string pointer
*string if you need
nil. Otherwise, use a normal string