[ruby-core:119879] [Ruby master Feature#20882] Provide Boolean(...)

Issue #20882 has been updated by austin (Austin Ziegler).


Dan0042 (Daniel DeLorme) wrote in #note-8:
> I would agree with any of these combinations, but not all of them at once.
> For example
> ```ruby
> puts "answer: yes or no?"
> p Boolean(gets.chomp)
> ```
> This will print "true" even if the answer is "t" rather than "yes", or if the user typo'ed "no" as "on". It seems to me pretty much every variation of this will need to distinguish between 2 values only, and accepting any of 12 preset values will lead to confused logic. "Be liberal in what you accept" but this seems a bit too liberal.

GitHub Actions takes what I think is the right choice for this:

```typescript
/**
 * Gets the input value of the boolean type in the YAML 1.2 "core schema" specification.
 * Support boolean input list: `true | True | TRUE | false | False | FALSE` .
 * The return value is also in boolean type.
 * ref: https://yaml.org/spec/1.2/spec.html#id2804923
 *
 * @param     name     name of the input to get
 * @param     options  optional. See InputOptions.
 * @returns   boolean
 */
export function getBooleanInput(name: string, options?: InputOptions): boolean {
  const trueValue = ['true', 'True', 'TRUE']
  const falseValue = ['false', 'False', 'FALSE']
  const val = getInput(name, options)
  if (trueValue.includes(val)) return true
  if (falseValue.includes(val)) return false
  throw new TypeError(
    `Input does not meet YAML 1.2 "Core Schema" specification: ${name}\n` +
      `Support boolean input list: \`true | True | TRUE | false | False | FALSE\``
  )
}
```

In the main cases where this is needed, one is pulling from an environment variable (which is always a string) or similar input. `Kernel#Integer` throws an exception if the value does not match the expectation of an integer (it is fairly *liberal* with what makes an integer, accepting decimal, binary, hex, and octal inputs). There is no reason that an equivalent `Kernel#Boolean` could not do the same and do so with exactly the six values listed above, *possibly* twelve if we wanted to accept symbol versions as well. I would argue that any other interpretation of a "boolean string" should be handled explicitly by calling `#==` or `#===` (via case) or with pattern matching because otherwise you are opening yourself to invalid or unexpected inputs, which are ultimately security risks.

----------------------------------------
Feature #20882: Provide Boolean(...)
https://bugs.ruby-lang.org/issues/20882#change-110571

* Author: getajobmike (Mike Perham)
* Status: Open
----------------------------------------
Ruby provides Integer(...) and Float(...) global methods to coerce values. Is there a similar method for Booleans?

I'd like to do something like:

```
# ENV["SOME_FEATURE"] is unset
Boolean(ENV["SOME_FEATURE"]) # => false

# ENV["SOME_FEATURE"] is unset, but allow a default?
Boolean(ENV["SOME_FEATURE"], true) # => true

# explicitly disable
ENV["SOME_FEATURE"] = "0"
Boolean(ENV["SOME_FEATURE"], true) # => false

# explicitly enable
ENV["SOME_FEATURE"] = "1"
Boolean(ENV["SOME_FEATURE"]) # => true
```



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/