html/template: ParseFiles throws away files with the same filename base

[bep]

go version && uname -a
go version go1.6rc2 darwin/amd64
Darwin bep-mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

See the file structure and the example program below.

This caught me by surprise; if this is the intended behavior, it should be made clear in the docs. You should also consider to return an error instead of silently doing the wrong thing.

package main

import (
    "fmt"
    "html/template"
)

func main() {

    /*

        /Users/bep/templ:

        ├── t1
        │   ├── t1.tpl
        │   ├── t2.tpl
        │   └── t3.tpl
        └── t2
            ├── t1.tpl
            └── t3.tpl

    */

    filenames := []string{"/Users/bep/templ/t1/t1.tpl",
        "/Users/bep/templ/t1/t2.tpl",
        "/Users/bep/templ/t1/t3.tpl",
        "/Users/bep/templ/t2/t1.tpl",
        "/Users/bep/templ/t2/t3.tpl"}

    templs, err := template.ParseFiles(filenames...)

    fmt.Println(err)                     // => <nil>
    fmt.Println(templs.Name())           // => t1.tpl
    fmt.Println(len(templs.Templates())) // => 3

    for _, templ := range templs.Templates() {
        fmt.Println(templ.Name())
    }

    // =>
    // t1.tpl
    // t2.tpl
    // t3.tpl
}

[bep]

An added note: The workaround in the case above is to use template.Parse in a loop.

[adg]

When we originally designed ParseFiles it was illegal to redeclare templates, and so it did indeed return an error. With the addition of the new block feature we removed the restriction on template redeclaration, and so now ParseFiles has this subtle behavior. That's not great.

We could patch up ParseFiles so that it does return an error in this instance, but we've already shipped a major Go version with this behavior and so people might be relying on it already.

That leaves us with a documentation fix, which is easily done. I will prepare it now, but I'm not happy about it.

cc @robpike in case he has other ideas.

[gopherbot]

CL https://golang.org/cl/21824 mentions this issue.

[bep]

We could patch up ParseFiles so that it does return an error in this instance, but we've already shipped a major Go version with this behavior and so people might be relying on it already.

As you have released more major versions with the correct behavior, I think that argument is a little bit thin. An error is more visible than a note in the doc.

[adg]

The new behavior is backward compatible with the old behavior, but not vice versa. We take compatibility very seriously, and cannot make backward incompatible changes without a very good reason. I don't think this meets the bar.