https://play.golang.org/p/3-iF20WnP2I demonstrates the same behavior in Go without templates.

It might indeed need a tweak to the spec. I'm not sure. Let's ask @griesemer

I think you should adjust the implementation of len to be in line with its specification. Go templates can never mirror the Go spec (this should be a good example). Untyped nils are way less obvious in a dynamic, non-static runtime.

But then again, I assume that a range over that same nil would fail, so I'm not sure ...

Reading the builtin godoc linked above:

Array: the number of elements in v.
Pointer to array: the number of elements in *v (even if v is nil).
Slice, or map: the number of elements in v; if v is nil, len(v) is zero.
String: the number of bytes in v.
Channel: the number of elements queued (unread) in the channel buffer;
if v is nil, len(v) is zero.

The way I'm reading it is that "if v is one of the types above and its value is nil, len(v) is zero". Perhaps that should be made clearer. In any case, I don't think it makes sense to allow len(nil) in Go or templates.

Actually, I misread the punctuation. It's actually saying:

• Array: the number of elements in v.
• Pointer to array: the number of elements in *v (even if v is nil).
• Slice, or map: the number of elements in v; if v is nil, len(v) is zero.
• String: the number of bytes in v.
• Channel: the number of elements queued (unread) in the channel buffer; if v is nil, len(v) is zero.

So this seems like just a formatting issue in the rendered godoc.

#7873 has a proposal for lists. The preformatted style intended for source code is very awkward for lists like this.

Thanks for the link, that's quite interesting. Though I think we can improve the situation here without waiting for a resolution to that issue. For example, we could make the channel line longer, or we could indent its continuation:

String: the number of bytes in v.
Channel: the number of elements queued (unread) in the channel buffer;
        if v is nil, len(v) is zero.

I do not think there is a compelling need to make len(nil) be zero. Remember an untyped nil is literally the constant nil; asking its length is pointless.

Other than possibly reformatting the text as suggested, I see nothing here worth doing.

Other than possibly reformatting the text as suggested, I see nothing here worth doing.

Makes sense. I think the confusion is that Hugo users may call range on an untyped nil and IIRC it doesn't error whereas a len check will error. Handling pointer references in go templates is a gotcha devs will need to learn unless there's some kind of affordance made to len in templates to make the following (example from Hugo) work without the use of default:

{{ range first 1 (default slice .Site.Params.images) }}
  <image>
    <url>{{ . }}</url>
  </image>
{{ end }}

@robpike note that the apparent consensus we reached is not about allowing len(nil), but rather about making len's documentation clearer. I'll send a CL shortly.

Change https://golang.org/cl/167403 mentions this issue: builtin: make len's godoc less ambiguous