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.

Revisiting this...

There are two separate proposals here:

1. Add a "is truthful" function that calls hreflect.IsTruthful
2. Add a cast.ToBool function that (among other things) calls https://pkg.go.dev/strconv#ParseBool

The primary driver for the first one was related to the old behavior of compare.Conditional where you had to do something like this with non-boolean arguments:

{{ compare.Conditional (1 | or | or) "doSomethingIfTrue" "doSomethingElseIfFalse" }}

We addressed that in #12870, and, based on forum activity, I haven't see any other need for this since this issue was raised three years ago.

The second proposal still has some merit, primarily in the context of evaluating boolean shortcode arguments when the content author does something like this:

{{< sc argument="false" >}}

We (I) handle that today with a construct such as:

It would be slightly more concise to do:

{{ $open := false }}
{{ if collections.IsSet .Params "open" }}
  {{ $open = cast.ToBool (.Get "open") }}
{{ end }}

But the above isn't really about casting a value; it's about parsing the value against an opinionated rule set to determines what is true and what is false (e.g., 1 is true but 1.1 is false, "true" is true but "foo" throws an error, etc.).

Given the confusion factor and its limited use, I recommend closing this issue and the associated PR.