My current workaround. It seems that if treated as an error, the right behaviour ensues.

tmpl, err := template.New("").Option("missingkey=error").Parse(text)
// supress/ignore error if it contains text "map has no entry for key" as missingkey=zero doesn't work currently on map[string]interface{}
if (err != nil && !strings.Contains(err.Error(), "map has no entry for key")) {
  /// normal error path.
}

I've been poking around a bit. The good news is that this edge case doesn't have any tests, so I don't think that the current behavior is locked into place. The only missingkey option tests use a map[string]int as the data type.

However, I am not convinced whether this is a good idea. I can understand that the code you provided behaves in a somewhat confusing way, but I imagine that forcing missingkey=zero to use empty strings as the zero value for interface{} types would also be confusing.

Take, for example, pipes. In those, a value is passed from one command to the next. In that scenario, passing untyped nil and "" are two very different things, and the former is the technically correct option when one is asking for the zero value of an empty interface type.

So I suspect that applying your change could break pieces of code with missingkey=zero, such as {{ .MissingIface | printf "%v" }}, as it would go from printing <nil> to nothing at all.

Something else that comes to mind is that you could use a workaround for this very specific edge case - that is, the edge case of needing zero values to be "stringified". I have written a simple example here: https://play.golang.org/p/f6hs0UiLX-I

$ go run f.go
<no value> -

Note that the example fails on 1.10 due to a bug with passing nil values to template funcs. It is fixed in master and will ship with 1.11, though: #18716

In summary, I don't think there's anything we can do here. Paging @robpike @rsc @ianlancetaylor to see what others think.

How about providing an option to allow the user to define their own behaviour through a function call?
That call would ultimately return a string which is substituted for the {{.Field}} text.

This would allow non-zero result substitution etc.

You mean an alternative to .Option("missingkey=zero")? Can you clarify how exactly that would work?

Such a suggestion should be a proposal; see https://github.com/golang/proposal.

I think that decision is best left up to the designer of the template engine. To me, it seems like an obvious feature that is missing which is to set a default value when a key is missing and not just substitute a zero value. This is done with flags in the case where a command line option is not provided there is the ability to set a default value.

Well, I'm precisely asking because I don't see an addition to text/template that would be simple and not interfere with the other existing options, such as missingkey=.

The only thing that potentially comes to mind is missingkey=emptystring or missingkey=empty, documented like:

The operation returns an empty string.

That would fix your initial example, I believe.

/cc @robpike, who is likely very opinionated about text/template's design.

missingkey=zero for an interface{} is a nil interface{}, which formats as <no value>. Sorry, but that's how the zero formats. The option is doing what it's documented to do.

@rsc any thoughts on my missingkey=empty idea above? It does seem to fit with text/template in my mind, although I'm not sure how badly it is needed.

@rsc - Personally I think setting the output as "" for a nil interface{} which eventually ends up as a piece of text as the result is not a good representation of no value. But an empty string "" (empty string) is.

But since you guys don't want to change it, people will forever be having to code around this.