text/template: interprets nil interface{} as a map

[walken-google]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   1.6.1
2. What operating system and processor architecture are you using (go env)?
   linux amd64
3. What did you do?
   http://play.golang.org/p/Fk7G5f3z1q
   The second template takes nil as its data, and accesses its .X field.
4. What did you expect to see?
   I would expect the second template to return an error, just like the first:
   template: :1:2: executing "" at <.X>: can't evaluate field X in type int
5. What did you see instead?
   The second template writes out "" and returns no error.
   This seems to correspond to the missingkey=default behaviour, which is documented to happen for maps. I don't think the empty interface should count as a map though, so I would have expected an error instead.

I can volunteer to provide a fix if the current behaviour is recognized to be a bug.

[walken-google]

The second templates writes out "no value" with <> around it. Looks like I couldn't just say that in the initial comment.

[adg]

Seems like a bug to me. Happy to review a fix.

[adg]

Oh sorry, there seems to be something missing in this report. You mention two programs, but I only see one?

Is <no value> not an acceptable output here?

[walken-google]

The program has two template calls in it - one with 0 as an argument, and one with nil. I would expect both to return similar errors, but the second succeeds. "no value" is documented behavior for maps, but not for the nil interface.

[adg]

Maybe I'm missing something, but the linked program only has one Execute call in it.

[walken-google]

Oh, sorry about that. Updated program is at http://play.golang.org/p/OaztWussVS - I did not realize that I needed to generate a new link after updating.

[adg]

This does seem like an inconsistency. I would expect both cases to return an error. But I think it has always been this way, and if we change it now, we might break existing Go programs, which we have promised we won't do.

[walken-google]

OK. we should probably close the issue then. Thanks!

[adg]

Thanks for the report.

[oec]

I just stumbled over this myself and I find the behavior annoying. I understand that we can not change the current behavior without breaking a promise, but could we maybe add another option for template.Option like "missingkey=error, just error!" that would trigger to handle the nil-interface case differently? I'd be happy to work on a patch for this.