Are we trying to do this:
https://pkg.go.dev/strconv?utm_source=gopls#ParseBool

Or "truthy" evaluation, e.g.
"something" => true

It needs to be truthy for it to be very useful.

To be clearer, in my head it should just use this: https://github.com/gohugoio/hugo/blob/master/common/hreflect/helpers.go#L63

Is someone going to get irritated with this?

{{ "false" | cast.ToBool }} --> true

Is someone going to get irritated with this?

Someone is going to be irritated by whatever we do. I would be very irritated if it was the other way around -- pick your enemy :-)

LOL

Maybe @carlmjohnson want to chime in on this, though.

The use case that I keep thinking about is:

{{< shortcode foo="false" >}}

{{ if cast.ToBool (.Get "foo") }}

{{< shortcode foo="false" >}}

I'm pretty sure you can do

{{< shortcode foo=false >}}

(the shortcode parser supports booleans and numbers)

I do see your point, though, for data coming in from misc. data sources, but I suspect there is a bad gotcha somewhere ...

I suspect it would be better to create two functions with different semantics: cast.TooBool and cast.ToTruth ... or something like that.

We've also trained people that "false" is false in some instances.

config.toml

buildDrafts = "false"

[params]
foo = "false"

template

{{ warnf "%T %t" .Site.BuildDrafts .Site.BuildDrafts }}  --> bool false
{{ warnf "%T %t" .Site.Params.foo .Site.Params.foo }}  --> string %!t(string=false)

And I've seen a lot of foo = "false" in config files.

I'm not advocating anything, just thinking of other cases where the function (or functions) might be used.

I think your examples would be better if you switched the flag:

buildDrafts = "true"

[params]
foo = "true"

They're still falsy when printed.

My expectation is that all strings are true except for the empty string. A separate helper that understands “false” and “0” as false would probably be okay, but I try to avoid that whenever I can.

Hi! If @carlmjohnson 's last comment is acceptable behavior, I'd like to be able to take up this issue as my first contribution! But if there's more discussion going on, I would agree that universally familiar truthyness behavior would be best, and leave it up to the user to handle cases like "false" and "0".

I started looking into this, and not is built into the Go template system (not a Hugo function), but it works by calling template.IsTrue. So the natural thing to do would be to write something like

func Bool(v interface{}) bool {
   b, _  := template.IsTrue(v)
   return b
}

The tricky part, which I didn't have time to figure out, is hooking it up to Hugo's system of template function namespaces and then writing some tests and documentation.

So, are we looking to extend this package?

I have re-labeled this issue as it's not really clear what we want to do.