The latest version of github.com/jba/templatecheck[0] supports templates
that cannot have type errors at execution time.
Once you've parsed your template `t` and all associated templates, call
ct, err := templatecheck.NewChecked[MyData](t)
If err == nil, then ct is a CheckedTemplate[MyData]. Its Execute method
will only accept a MyData, and execution will not fail because your
template tried to access a field that didn't exist, or tried to range over
something that doesn't support range, or any other problem related to types.
To make this guarantee, the type checker enforces a stricter semantics than
the usual one for templates. For example, when you create a variable with a
value, like this:
{{$v := 1}}
then all assignments to that variable must use the same type. Assignments
that are normally valid, like
{{$v = ""}}
will fail this stricter check.
Also, since there is no way to declare the type of a template created with
{{define "T"}}, all calls to such templates must use the same type for dot.
If you can live with these restrictions, you might like using
CheckedTemplate[T] for the extra safety it provides.
I'd like feedback on how difficult the stricter semantics is to work with.
In particular, how painful is the restriction that all calls to associated
templates must have the same type?
I'd also consider proposing this for the standard library if a lot of
people like it.
[0] https://pkg.go.dev/github.com/jba/templatecheck
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEymQsSqVjw4KXVUvz2k6s9Hup4mgjUZ-DZWcn%3DH1FmbuJUXdg%40mail.gmail.com.
