text/template: integer literals wrapped in parens don't act as untyped constants

[jo3-l]

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

$ go version
go version go1.16.2 windows/amd64

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
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Joe\AppData\Local\go-build
set GOENV=C:\Users\Joe\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Joe\Documents\Code\golang\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Joe\Documents\Code\golang
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.2
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Joe\AppData\Local\Temp\go-build716891636=/tmp/go-build -gno-record-gcc-switches

What did you do?

I ran this script: https://play.golang.org/p/0nprITNVbYP

What did you expect to see?

I expected to see

template without parens executed successfully
template with parens executed successfully

printed to standard output.

Per the text/template documentation on arguments:

A boolean, string, character, integer, floating-point, imaginary
or complex constant in Go syntax. These behave like Go's untyped
constants. Note that, as in Go, whether a large integer constant
overflows when assigned or passed to a function can depend on whether
the host machine's ints are 32 or 64 bits.

As such, I thought that passing (1) to the function would have had the same effect as passing 1 - that is, both are interpreted as untyped constants and are accepted as arguments of type time.Duration. Furthermore, a similar program in Go not using text/template works fine - given a function f that accepts one argument of type time.Duration, f(1) and f((1)) both work correctly. See https://play.golang.org/p/f-BvvUqA9Y_o.

What did you see instead?

I saw

template without parens executed successfully
error executing template text with parens: template: with_parens:1:5: executing "with_parens" at <1>: wrong type for value; expected time.Duration; got int

printed to standard output, seemingly showing that (1) was not interpreted as an untyped constant while 1 was.

[cherrymui]

cc @robpike @mvdan

[robpike]

I feel this is to be expected. In the template language (1) is not a parenthesized 1, it is a pipeline that evaluates to 1. The syntax of arithmetic in templates is not "standard" mathematical notation. In order to evaluate (1), it needs to have a type, and in isolation (through bottom-up execution) there is no indication to the template executor that it needs to be a time.Duration.