Unmarshaling of front matter produces incorrect data types for some slices

[jmooring]

This is not a new issue. It has been present since v0.54.0 (and perhaps earlier).

Front matter:

+++
s = [1, 2, 3]
+++

Template:

{{ range .Params.s }}
  {{ fmt.Printf "%[1]v (%[1]T)" . }}
{{ end }}

Actual:   1 (string) 2 (string) 3 (string)
Expected: 1 (int) 2 (int) 3 (int)

The front matter format (JSON, TOML, or YAML) is irrelevant.

The transform.Unmarshal template produces the expected results:

{{ $t := `s: [1,2,3]` }}
{{ range (transform.Unmarshal $t).s }}
  {{ fmt.Printf "%[1]v (%[1]T)" . }}
{{ end }}

--> 1 (int) 2 (int) 3 (int)

Reference:
https://discourse.gohugo.io/t/42141/2

[bep]

As I read the code, this happens with non-string slice types (e.g. ints in the example above). This has probably been the case since Hugo 0.10 or something ... I have no clue why this behaves the way it does; I will create a PR and see if some tests blow up.

[willfaught]

@bep Regarding the original context of that thread, please also ensure that mixed types (like strings and maps, regardless of the type of the first element) in a list result in a []any type. 🙏

[bep]

@willfaught have a look at the 3 test cases here: https://github.com/gohugoio/hugo/pull/10625/files#diff-9536370a7750aee5a746670c7adefeb0d62de88a150bb8fea9a7d3597f2219cfR43-R45

[willfaught]

@bep Thanks for adding that. Assuming the mixed int/string case covers the map/string cases, where the type is []any if the first element is map and the rest of the elements are strings, or vice versa, then it LGTM. It looks like @jmooring tested that specifically separately and it works.

[bep]

@willfaught yea, the new logic is that if []any and all elements are strings the convert to []string, else keep as is.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.