New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
text/template: pointer to empty slice/map considered truthy #51816
Comments
cc @robpike |
You quote the documentation, which says that a nil pointer is considered to be empty. It follows that a non-nil pointer is not considered to be empty. And |
Thanks for the response. Fair point about the documentation; I missed that when reading. With that said, I would point out that the documentation is also somewhat contradictory in the other direction: calling the Additionally, the logic that a nil pointer is considered to be empty implies that a non-nil pointer is not considered to be empty does not feel completely sound to me. For example, if we apply similar logic to the statement nil interface values are considered empty, which is also in the documentation, we get that non-nil interface values are not considered to be empty, which is incorrect: package |
We would be happy to take specific suggestions for improving the documentation. It's true that operations like In any case the behavior is documented and is working as documented. If we change that behavior now, we will certainly break some existing code. We would need a very strong reason to make such a change, a reason much stronger than "it would make the various operations more consistent" (and I'm not even sure that it would make the operations more consistent). |
Thanks for the explanation. While I do not fully agree with it, I understand the standpoint and agree with the importance to maintain backward compatibility. I do think the documentation regarding when values are indirected could be improved, but I do not have a specific suggestion at the moment. (If I do, I will fill another issue.) For what it's worth, a user of an application I contribute to came across this behaviour and found it inconsistent as the distinction between pointer and non-pointer values is otherwise mostly opaque for template users. It's not a major issue for us as we maintain a fork of package Given that I don't have a more convincing reason than consistency, closing. Thanks again for your time. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes; checked with Go 1.18 and tip on the playground.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Executed the following template using
text/template
:where
PtrEmptySlice
is&[]int{}
andEmptySlice
is[]int{}
.Go playground link.
What did you expect to see?
false
for both the pointer to the empty slice and the empty slice; the text/template documentation gives the following description for theif
action:While pointers to arrays, slices, maps or strings are not explicitly mentioned, the rest of the documentation sets a precedent that when it refers to an array, slice, map or string, pointers are also accepted and indirected prior to being handled. For example, while the description for the
range
action does not explicitly state that it handles pointers to arrays, slices or maps, in practice it also accepts items of these types.Similarly, most built-in template functions indirect their inputs before working with them. For example, the
len
built-in reports0
for both the pointer to the empty slice and the empty slice, meaning that in certain cases the output for the twoif
actions below differs, which is unintuitive:Given all this, it seems reasonable to me that pointers to empty values should also be treated as empty values, for consistency purposes. While this is inconsistent with the Go language, it is notable that the existing definition is already so; slices of length zero are not zero values for their type in Go, but are treated as such in package
text/template
.What did you see instead?
true
for the pointer to the empty slice andfalse
for the empty slice.The text was updated successfully, but these errors were encountered: