Thanks for the issue report.

Issue #18816 may be somewhat relevant.

Template 3 is just the control for arrays
Template 4 shows that this does work in arrays (presumably because arrays are more pointer than value)

I see that you're using slices in template 3 and 4. Did you mean to say slice instead of array?

That the call to the method with a pointer reciever would behave the same in the template as in regular Go syntax.

I think there's an inconsistency in that you're using a local variable d in your test:

d := Data{Field: "test"}

That means when you write d.PrintPointer(), Go interprets that as (&d).PrintPointer(). It takes the address of the local variable d, resulting in *Data, and then calling its PrintPointer method. This is described in https://golang.org/ref/spec#Calls, specifically:

If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m():

var p Point
p.Scale(3.5)

Take a look at https://play.golang.org/p/qsyqsjW3i7Z.

If you change it to use a Data struct literal directly (see https://play.golang.org/p/-7Q7YRalYp_K), you get the same error in Go syntax as you do from the template execution:

./prog.go:7:21: cannot call pointer method on composite literal
./prog.go:7:21: cannot take the address of composite literal

If you apply the changes above to the original playground snippet, then everything looks consistent:

https://play.golang.org/p/h31FBL_qCIV

/cc @mvdan per owners.

I see that you're using slices in template 3 and 4. Did you mean to say slice instead of array?

I did mean to say slice.

If you change it to use a Data struct literal directly (see https://play.golang.org/p/-7Q7YRalYp_K), you get the same error in Go syntax as you do from the template execution:

That clears up the confusion. Thank you.

I looked into it a little more and it seems it does not work in the template because the reflect package can not address the value in the template (ptr.CanAddr() returns false) - which makes sense as it is not a pointer. I don't know if this behavior should be changed, and if so, how.

That clears up the confusion. Thank you.

Glad to hear that.

I looked into it a little more and it seems it does not work in the template because the reflect package can not address the value in the template (ptr.CanAddr() returns false) - which makes sense as it is not a pointer. I don't know if this behavior should be changed, and if so, how.

That's right, the value needs to be addressable.

I don't think anything can or should be changed in text/template. It's common to pass a pointer to a struct to Execute for this reason, and also because it can be more efficient if the template data is large enough that copying it by value is expensive.

I'll close this since there's nothing to do here. Let me know if you disagree.