text/template: handling of `nil` keyword

[mxxk]

What version of Go are you using (go version)?

$ go version
go version go1.19.5 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/user/gLibrary/Caches/go-build"
GOENV="/Users/user/gLibrary/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/user/g.asdf/installs/golang/1.19.5/packages/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/user/g.asdf/installs/golang/1.19.5/packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/user/g.asdf/installs/golang/1.19.5/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/user/g.asdf/installs/golang/1.19.5/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.19.5"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kq/zqxnkcz94n97q3qrpvtl16l00000gn/T/go-build3844177246=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

These templates were evaluated to demonstrate how the argument nil is handled:

• {{nil}}
• {{print nil}}
• {{nil | print}}

Source (go.dev/play/p/ZUCywuoOq7E)

package main

import (
	"fmt"
	"os"
	"text/template"
)

var templates = []string{
	// Examples using `nil`
	"{{nil}}",
	"{{print nil}}",
	"{{nil | print}}",
	// Examples using `true`, for comparison
	"{{true}}",
	"{{print true}}",
	"{{true | print}}",
}

func main() {
	for i, templateSource := range templates {
		name := fmt.Sprintf("Template %d", i)
		tmpl := template.Must(template.New(name).Parse(templateSource))
		fmt.Printf("# %s\n", name)
		if err := tmpl.Execute(os.Stdout, nil); err != nil {
			fmt.Println(err)
			continue
		}
		fmt.Println()
	}
}

What did you expect to see?

According to the text/template docs, nil is a valid standalone argument:

Arguments

An argument is a simple value, denoted by one of the following.

• A boolean, string, character, integer, floating-point, imaginary or complex constant in Go syntax. [...]
• The keyword nil, representing an untyped Go nil.

Based on the above, these are expected to render:

Template	Expected result
{{nil}}	<no value> (how nil value renders)
{{print nil}}	<nil>
{{nil | print}}	<nil>

What did you see instead?

Template	Actual result
{{nil}}	Error: "Template 0": at <nil>: nil is not a command
{{print nil}}	<nil>
{{nil | print}}	Error "Template 2": at <nil>: nil is not a command

If the observed behavior is actually correct/intentional, then should the docs be updated to reflect this?

[ianlancetaylor]

I agree that the behavior does not seem to match the documentation, but as the current behavior seems reasonable I think we should probably just adjust the documentation.

CC @robpike

[mxxk]

Thanks @ianlancetaylor. Would you mind sharing your thoughts on how the current behavior seems reasonable? Or perhaps it is simply easier to adjust the docs rather than the logic for compatibility purposes?

Personally, the handling of nil (as opposed to other keyword constants, such as true) seems a bit confusing/surprising, but perhaps I'm missing something here.

Stepping back a bit, the current documentation seems to suggest that {{nil}} should renders to <no value> based on the following excerpts:

Documentation snippets

---

1. An action may be a pipeline:

   Actions

   {{pipeline}}
          The default textual representation (the same as would be
          printed by fmt.Print) of the value of the pipeline is copied
          to the output.
   

2. A pipeline may be an argument:

   Pipelines

   A pipeline is a possibly chained sequence of "commands". A command is a simple value (argument) or a function or method call, possibly with multiple arguments:

   Argument
   	The result is the value of evaluating the argument.
   

3. An argument may be the keyword nil:

   Arguments

   An argument is a simple value, denoted by one of the following.

   • The keyword nil, representing an untyped Go nil.

---

Presently, the cases below seem non-trivial to justify, for example:

Template	Result	Justification
{{print nil}}	<nil>	nil is a valid argument to a function
{{nil}}	Error	nil is not valid as a standalone argument
{{print true}}	{{true}}	Non-nil constants are valid in both of the above contexts

[ianlancetaylor]

It seems reasonable to me because {{nil}} doesn't have a type, and because there is code in text/template that is clearly implementing this behavior and there are tests that are checking for it. My experience with text/template is that changing it causes people's existing templates to break, though I admit I don't see how that could happen in this case.

I'm not strongly opposed to changing the behavior, but I would not be at all surprised if we have to roll it back.

Perhaps I should ask: what is your use case here?

[mxxk]

Appreciate the clarification!

Perhaps I should ask: what is your use case here?

I actually came across this behavior on accident, without a concrete use case to stake on. I was experimenting with {{define "helper"}}...{{end}} followed by {{template "helper}} and {{template "helper" nil}}, and was surprised that the former passed nil to "helper" while the latter errored.

The question in this issue appeared by isolating the behavior to a minimal reproducible example. 🙂

[robpike]

See my closing comment in #57773. Infeasible.